Infrastructure for meta-distribution projects

[Ben Armstrong]

On Wed, Jun 04, 2003 at 11:33:18AM +0200, Andreas Tille wrote:
> Ben did not adopt this for his packages because he does not even use debhelper
> because of speed issues.

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.

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.

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

> I'm not sure about that.  My prefered way is to build a Knoppix derivate
> which contains all Debian-Med stuff.  For this purpose I try to implement
> a new system which makes it brain dead easy to build Knoppix CDs from
> the Debian-Mirror.  The problem is that this system is currently plain
> fiction ...

OSEF has already made a Knoppix CD including Debian Jr.  However, that 
continues to be a hand-tailored thing, afaik.  See http://www.osef.org

> 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

Feel free to re-open the bug and state your case for it.

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   synrg@sanctuary.nslug.ns.ca
 \`'  Debian   http://www.debian.org    synrg@debian.org
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]