On Sun, 2006-04-23 at 12:23, Javier Fernández-Sanguino Peña wrote: > Hmmm... I'm not an expert but I think it goes like this: > > - metapackage in 'testing' which (unversioned) depends: A and B > (in testing A, version 1, and B, version 1, get along together) > - The maintainers decide that, for sid, A will have new functionality > that makes it replace B. So, in sid, A (v2) conflicts: with B (v1) > > In this situation, unless the metapackage is updated to reflect that change > then A could not get into testing without breaking the metapackage (and the > migration scripts would prevent that unless forced^Whinted to do so). > > If the maintainers managing the packages and meta-packages don't sync their > work there is going to be breakage because of the later. The above is a > simple example but things can easily get more complicated with metapackages > that depend on *lots* of other packages. Users end up having to remove the > meta-package (either manually, or because apt says so), losing the benefits > they provide.
Thanks. I can see how some kind of O(N*2) effect could make that difficult for Ubuntu-style metapackages with hundreds of dependencies. However, metapackage equivalents of Debian tasks would have much more reasonable numbers of dependencies - I think "desktop" is the most complex with 18. tasksel is a separate parallel unnecessary superfluous redundant and largely opaque dependency lattice with some dependencies not even determined until runtime (Test: ) and a whole set of action scripts (postrm etc) independent of regular package scripts. Far better to put the information in the standard dependencies of a simple package which everything understands already (and which tasksel could use to ensure consistency). Many people prefer tasksel. That's great. Go for it. But please don't ban meta-packages for those of us who want the simple solution which package dependencies provide and which our programs can understand. Thanks for listening, --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
