[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[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

> > 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


Reply to: