Excessive package interdependency

[Stefan van der Eijk]

Perhaps off topic, but here's how we introduced automatic dependencies 
between -devel packages at Mandrake:

http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies


Nicolas Mailhot wrote:

> Nils Philippsen wrote:
>
>> On Fri, 2003-12-19 at 07:50, seth vidal wrote:
>
>
>>> it'd be handy to know what a user selected group-wise.
>>
>>
>>
>> When reading this thread I had the idea, that _if_ an RPM package could
>> "suggest" other packages/dependencies this should be doable.
>
>
> In-package suggestions has lots of drawbacks :
>
> - it's unidimentional - you can not do suggestions following different 
> suggestion logics (well you can but the user will have *lots* of 
> trouble following you)
>
> - it forces everyone to repackage software every single time you want 
> to change suggestions. This is a big problem - it hurts third-party 
> repositories, you end up re-building and re-QAing perfectly sane 
> packages (from a system point of view)
>
> - it hides the big picture from the packager. While system 
> dependencies must be consistent and the package manager will force 
> both packager and user to respect them, with in-package suggestions 
> it's real easy to get foo suggest bar which suggests baz but baz does 
> not play well with foo. (just think : gnome suggests artwork which 
> suggests kde)
>
> An external overlay is much more sensible. You can have several 
> profiles re-using the same packages with following different logics, 
> third-party sites distributing profiles that use core components 
> (example - freeworld music profile with mp3 addons...), updated 
> profiles without mass-rebuilding, etc. Remember - it's named 
> dependencies too but it is not system dependencies. The core rpm 
> system does not care at all about them - it can work without them very 
> well like today. There is absolutely no reason to force them into the 
> packages themselves, except that another well known system did it for 
> years (and RH people kept repeating it was a bad idea).
>
> Stop thinking complex recursive multi-level hierarchical integrated 
> systems. We are targeting humans. Humans are lazy (or dumb, depending 
> on your worldview). A human can only easily grok short flatlists (like 
> in anaconda groups today). Anything more complex would be self-defeating.
>
> Cheers,
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031223/9878827e/attachment.bin>