[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 <[EMAIL PROTECTED]>
