Re: Getting 3rd party RPM's via an OS installer?

[Dan Stromberg - Datallegro <dstromberg datallegro com>]

On Tue, 21 Aug 2007 18:23:11 +0200, Tony Earnshaw wrote:

> Dan Stromberg - Datallegro skrev, on 21-08-2007 18:05:
> 
>>> Dan Stromberg - Datallegro wrote:
>>>> But some of these 3rd party RPM's aren't very careful
>>>> with their Requires dependencies,
>>> Don't you just hate that?
>> 
>> Yeah, it's a pain.
>> 
>>>> Is there some way of constructing a special RPM that
>>>> should always be installed at the end of the tested
>>>> RPM's, and change minimally your 3rd party RPM's to
>>>> depend on that single RPM?  That is, without having
>>>> a huge list of Requires in that special RPM?
>>> You could create an rpm that depended not only on the 3rd party rpms
>>> but also on the dependencies that you have deduced are required.  Then
>>> install your rpm and it should bring in all of the dependencies.
>> 
>> Say the special RPM is called "knot".
>> 
>> Wouldn't you need to make your 3rd party RPM's require knot, and make knot
>> require anything the 3rd party RPM's require?
>> 
>> I'm no RPM expert, but it seems like if knot required the 3rd party RPM's,
>> it'd be installed after the 3rd party RPM's, and the 3rd party RPM's
>> remain at the mercy of the topological sort. Or am I missing something?
> 
> Well, since I moved from up2date to FC6, and then CentOS5 and RHL5, I've 
> found that yum is pretty good at sorting out dependencies (unless one 
> chooses stupid repositories - in which case all hell breaks loose).
> 
> With correct repositories (yeah, I once "updated" my whole FC7 
> installation with FC8 stuff) I've found yum to be unparalleled.
> 
> Anybody's shout :)

IINM, yum's (and similar tool's) ability to deal with dependencies is only
as good as the Requires data inside the RPM's - but I'm faced with some
RPM's that don't have good Requires data.  These troublesome RPM's are
assuming that the OS is already 100% installed and so do not need to
Require individual parts of the OS, while with the installation method
we're looking at, that isn't true - so for example a driver RPM that uses
"which make" without depending on the "which" package, can run into
trouble in this context, while it wouldn't in most contexts.