RPM Help Needed

[David Relson]

On Tue, 30 Dec 2003 19:42:57 -0500
Gyepi SAM <gyepi at praxis-sw.com> wrote:

> On Tue, Dec 30, 2003 at 07:01:07PM -0500, David Relson wrote:
> > Greetings,
> > 
> > I need some help with bogofilter's rpms.
> > 
> > Having recently upgraded my workstation from Mandrake 9.1 to 9.2,
> > the rpms I build have a couple of Mandrake specific dependencies,
> > i.e. perl(MIME::Parser), perl(POSIX), and perl(strict).  An rpm
> > built with these dependencies won't load on older versions of
> > Mandrake, for example 9.1.  I presume there will have comparable
> > difficulty with other distributions.

It puzzles me that, all of a sudden (with MD9.2 and bogofilter-0.15.13),
there are now 4 perl dependencies when there used to be 0 of them (with
MDK9.1 and bogofilter-0.15.7).  I'd like to know _why_.

> > I have tried using "%define _requires_exceptions ..." statements,
> > but can't make all 3 dependencies go away.  At best I can make 1 of
> > the dependencies go away.
> 
> You can frequently define vendor (or other macro) specific components
> of an rpm file:

...[snip]...

Can a requires say "db3 >= 3.3 or db4 >= 4.1" ?

> do 'rpm --showrc' for all the gory possibilities.

Approx 570 lines for 289 active rules, several mentioning perl, but none
mentioning the 3 that are being troublesome.

> But that gets tiresome very quickly. With respect to the dependencies
> you list, all relatively recent versions of perl provide perl(POSIX)
> and perl(strict) so there's no need to include them specifically. If
> you really want, add a Requires tag for perl. The requires on
> perl(MIME::Parser) is being generated by contrib/mime.get.rfc822.
> Since this is an optional, contrib file, we should ignore its
> dependencies. A note in the documentation should suffice.

Can we tell RPM to ignore the dependency?  It'd be nice to have
bogofilter install cleanly, without having to use "--nodeps" (or
whatever).

> I recommend that we not not generate dependencies automatically.
> Matthias sent an email to the effect that we should re-enable it, but
> there are other solutions, which I'll address in another email.

I'm looking forward to seeing your solutions.  It's good to know we have
a member of the team who's knowledgeable in these matters.

Thanks, Gyepi.

David