Excessive package interdependency

Nicolas Mailhot Nicolas.Mailhot at laPoste.net
Tue Dec 23 13:08:04 UTC 2003


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,

-- 
Nicolas Mailhot






More information about the fedora-devel-list mailing list