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.
Description: S/MIME Cryptographic Signature