[Internal] Re: Infrastructure for meta-distribution projects
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.
Reply to: