On Wed, 4 Jun 2003, Ben Armstrong wrote: > To elaborate: I considered building all junior-* packages from a single > source, but instead opted to build them individually from a minimal package > template. This allows me to de-couple the release cycle for each meta > package from each other. You may wish to get the latest > "junior-programming" but not bother with the latest "junior-arcade" for > example. I also prefer independent metapackages.
> The approach is imperfect, though, because the templating is not automated. > I simply copy an existing meta package and hand-edit to create a new one, so > if I ever need to fix my template, I need to go back and modify every single > package. This is tedious. I'd love to redo it with a common package that > generates individual minimal meta packages (maybe with something like > equivs). The tool should allow me to maintain lists of dependencies and > changelogs for each individual meta package all in one place. It should > also allow me to generate a new version of a single meta package without > rebuilding all of the others, or automatically bump up the version# and add > the same changelog entry to all meta packages if I make a global change. Very interesting. I'd like to see your solution ... > > > With the new package tags system (although not integrated into the > > > installer yet), we can presumably do away with this. > > I hope so. I have to admit that I did not had a deeper look but it seems > > reasonable and promissing for our purpose. > > Do we really want to kill the meta package approach? Definitely not!!! Perhaps I was not clear about this point. > Tags allow flexible > selection by the user of an appropriate set of packages using arbitrary > criteria. Meta packages specify a precise list of packages to install. I > think the meta package approach will continue to be a reasonable way to > install a default set of packages, whereas tags give the user the ability to > fine-tune package choices without having to slog through several thousand > packages to find appropriate ones. What I intended to say was that - provided there are useful tools to handle tags - this could be an interesting add on to care with internal projects stuff. > > For sure we should collaborate here. That's why I would love to move this > > thread to a public mailing list (prefered debian-internal - but this list > > is not yet created :-(( - and I can't even find the bug report with the > > request - I'm sure I filed it long time ago). So feel free to quote me > > on debian-devel. > > The bug was closed. The list maintainers said a separate list wasn't > warranted. Look in the archived bugs for lists.debian.org and you'll find: > > http://bugs.debian.org/160229 Many thanks for the hint! > Feel free to re-open the bug and state your case for it. But not me. Sorry, I'm burned out here. I think I will continue to post messages to debian-devel tagged with [internal] to make people notice that THERE IS A NEED. Perhaps somebody else wants to reopen. Kind regards Andreas.
