Infrastructure for meta-distribution projects

[Enrico Zini]

[I'm preserving the list of CCs, altough I'm fearing it's getting quite
long]

Sorry for intervening this late in the discussion, but I've been away
for some days and found my home server with a broken power supply and
motherboard on return.

We're finally addressing the issue of what structure and data is
required to build a metadistro.

These are the proposals I've seen so far in the thread:

 - The Debian Package Tags
 - Task packages
 - Meta packages

Using package tags to select the packages that go in a subdistro would
require to have subdistro-dependent informations inside the main package
tag database.  Instead, I designed the system to support local addition
of tags for subdistro-specific needs.  The idea is that the central
database should contain only well-defined and generally valid tags, and
subdistros could locally add informations that is subjective to their
field of use, but would make no sense outside their context.

To do this, subdistro packagers just need to install definition for
custom tags in /etc/debtags/tagvoc.d (using the same syntax of
/var/lib/debtags/vocabulary) and tag patches in /etc/debtags/tagpatch.d
(tag patches can be generated by editing the master database with
tagcolledit and producing a diff with "debtags diff").  I'd be happy to
assist in this process, so that I could get feedback on it from the real
world.

I think that producing a subdistro needs a customization of more than
package tag data: I could see a need of overriding standard package
fields like "Priority:", "Suggests:", "Recommends:", maybe "Depends:"
and probably also "Description:".

I'd consider the idea of maintaining a local customization of the
package database, that could be applied when burning a CD with the
subdistro or shipped in some other way, so that it could be used to
change the "personality" of the Debian system one would want to use.

Just manipulating the "Priority:" field could provide the way to select
which packages would be part of a subdistro.  All the rest would help
making the subdistro run smoothly.

Most important, once Debian would be able to find and apply those
patches, they could be maintained outside of Debian, opening the way for
many subprojects to come to light.

I quite like the idea that a guy in charge of a university lab with lots
of workstations could maintain his "lab subdistro", for example, and
this indeed requires de-centralization and the possiblity that a
subproject could be maintained without the need for Debian to know about
it.  This independent patches could make it possible.

A possible package database patch could be just a normal package
database, but with incomplete records.  When applied, the contents of
the records could go and override what's in the main database.

For example (for debian-med):

----------------------
Package: bioperl
Priority: important

Package: gnutrition
Priority: important

Package: menu
Priority: standard

Pckage: traceroute
Priority: optional
----------------------

Metapackages could then be used to bring in selections of packages (like
med-imaging or med-bio do), and maybe the need for metapackages could go
away in some future when package managers will start making use of
package tags.


What do you think of the package database patch approach?


If we like it, we could start thinking practical: could it be
implemented right now or should we find another way to make subdistros
until tools are updated to support it?


> Also, does anyone feel that there should be a separate installer that
> installs Debian-Lex by default instead of just Debian?  That way, we can
> hand it to a user and say "Here is a Debian-Lex CD" rather than "Here is
> a Debian CD, and here is some documentation about how to use it to
> install Debian-Lex".  Ideally, this ought to just involve a simple
> change to Debian Installer or boot-floppies, without the need to change
> anything else in the main distribution (a la Knoppix).  Logically, all
> the meta-distributions ought to collaborate on this.

As I see it, this is going to become the standard way of distributing
Debian: start with a specialized distro, then hook into the main archive
for further packages.  The specialized distribution could then be
shipped in a knoppix-like fashion, run from CD and installed on disk
with a few clicks.

If we can make it easy to build and maintain a subdistro, communities
for many possible usage goals could form and maintain all needed
specializations.  We could then have a plethora of specialized debians
one could pick from and just use, and all of them subdistros will
be just the minimum possible customization from the commonly maintained
Debian universe.  Minimum duplication of efforts, maximum user
satisfaction.

Can you see the power of this approach?

I'll really want to discuss about this at the Debconf in Oslo: be
prepared when you meet me :)


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

Why don't we setup a working group on this during the debcamp?


Ciao,

Enrico


--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>