On 08/14/2011 07:23 PM, Jean-Michel Philippe wrote: > Alright then, sure I knew the rules!
Do we have a concrete case of this to discuss, or are we still talking about hypotheticals? The reason I ask is, I know for certain dependencies (gnome metapackages mostly, but others may exist,) there have been prior bug filings tagged 'wontfix', so before expending the effort, it's a good idea to check that out first. In the case of metapackages it is more of a judgement call of the developer than a strictly technical argument about what is needed and what isn't because a metapackage is nothing more than a convenience. What the developer who maintains it finds convenient may not be what you find convenient. In such a case, it's probably better to come up with a metapackage of your own than to try to argue with the developer on the issue. >> If a conflicting package is installed on the system you can not install >> the metapackage and the package management program (aptitude, synaptic, >> ...) will warn you about this and ask for advise. > > Do you mean we could partly remove dependencies of a meta-package by > putting it in a broken status? So now we're talking about metapackages ... OK. We've kind of flipped topics, then, from talking about wrong dependencies that bloat a package vs. dependencies that are inconvenient in a metapackage that bloat our CD image. Let's make sure we're on the same page. As for stating a conflicts to negate recommends from a metapackage, I think this may cause more problems than it solves, as a recommends is "soft" (you can remove a package that is recommended without breaking anything) but conflicts are "hard" (once you conflict with a package you can never install it without removing the conflicting package!) So we sacrifice flexibility. Pinning doesn't have this problem, if done properly, as it can give us precisely the amount of flexibility we want, no more and no less. Ben -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
