Relevant posts in debian-devel with material that can be relevant/recyclable for this manifesto.

This list is definitely not complete

cobaco:

A CDD is Debian, the only difference is that the default setup is customized for a certain purpose/situation out-of-the-box.

Ideally all changes necessary to Debian to support that out-of-the-box situation are merged back into Debian ASAP, not merging back changes only increases the workload for the CDD, which thus has no incentive to keep changes to outside of debian if it is feasible to merge them back in.

SO: A CDD focusses on providing support for a certain target group/situation within Debian, as such we'll work within Debian as much as possible. We might have to experiment with things/ways of doing stuff not currently possible in Debian, but the intention is always to get things back into standard Debian, thus improving the whole distribution.


enrico:

I see no problems in documenting that the name "Custom Debian" includes "Flavours" and "Derivative Distros", and then define what they are.

It would be a nice way to make sure that we all agree with the meaning of terms, to ease further discussion. For example, I have a clear meaning for Custom Debian, but I don't know how shared it is.

On the other end, I feel that if you see Flavours and Derivative Distros as subsets of Custom Debians, then we might have different concepts in mind.

We seemed to agree that Custom Debian's goal is to have distributions which are 100% Debian, with a different default package selection and a set of policy-compliant customizations.

With my ideas of Flavours and Derivative Distros, Flavours are Custom Debians, but Derivative Distros are things like Knoppix which are derived from Debian but are not policy compliant, and so they can't be called Custom Debians.


aj:

Okay, IMO there are two techniques worth distinguishing that both aim to achieve the same goal. That goal is to put a CD (or DVD, or mirror) in the hands of a user, who can use that CD to get a running, dpkg-based system that does a particular thing s/he wants, and nothing else. If s/he wants to setup a multimedia box that records TV programs and acts as an mp3/ogg jukebox, that's the only sort of software s/he sees -- no web proxies, no intrusion detection tools, no compilers, no documentation on setting up RAID arrays and hot-failover. If s/he wants to setup a fileserver for a small business, s/he might see Samba and Appletalk and NFS, but there won't be any games or scientific analysis tools available.

The issue isn't so much one of removing those tools entirely -- ideally, they'll just be an apt-get away anyway -- but of putting the things that are actually wanted on the first CD (or at least the first few ["CDs"]), and making the installation and configuration process as quick and easy as possible.

I think "Customized Debian" is a good name for that sort of thing -- it's Debian, but it's customised for particular usage scenarios. If the usage scenario is common enough, then that's a real win: one person can do the customisation, and hundreds or thousands can reap the benefits.

> On the other end, I feel that if you see Flavours and Derivative Distros > as subsets of Custom Debians, then we might have different concepts in > mind.

Now, there are different possible approaches to this. The most flexible is to create a "Debian derivative" -- that is, to take Debian, pull out the bits you like from it, upgrade some things, downgrade others, recompile some of the stuff that doesn't work quite right, improve a few things, and add some completely new stuff. That's great, and it's been demonstrated to work quite well.

The problems are straightforward: if you're writing your own stuff, you have to manage your own security updates. If you're forked from Debian, then Debian might make some changes that break compatability with your stuff, and you might have to think a bit to integrate the changes. You'll need to find someone to host your images. You can't leverage most of the Debian infrastructure (BTS, autobuilders in particular, probably).

But there are plenty of benefits too: you don't have to worry about non-i386 if you don't want. You can set your own policies and not have to answer to anyone, or convince anyone they're good. You can set your own schedule. If you've got software that Debian can't distribute (it costs money per copy or it's internal-use-only, eg), you have to go this way, to some extent.

So that's what I call a Debian derivative. It's obviously a customised Debian, but it's customised by taking Debian and adding stuff to it.

While that's by far the most effective way of customising Debian, it's not the only conceivable way. The other conceivable way to customise Debian is just to look at all the packages, and rm the ones you don't care about. If that gives you want you want, you overcome a bunch of the more annoying shortcomings above: you don't have to do your own security updates, you don't have to arrange your own hosting, new upstream releases will be packaged for you without you having to lift a finger, it'll normally work on all supported architectures without any effort, and you can file bugs in the BTS without anyone caring that you didn't install from an official Debian CD.

That's what I'm calling a "flavour" of Debian. A different analogy which makes a little more pedagogical sense is to consider it a "shade" of Debian -- making the analogy with colours and prisms instead of taste. Debian, the universal operating system, beams white light at you all day long, and you put a prism or a filter in its way to get just the "shade" of Debian that you want. We do this already by choosing which packages we want on individual systems and setting them up, which is fine; but what we really want is to be able get a pre-fab filter from the store, and just plonk it in, so we don't have to bother ourselves all the time. We can do that to some extent at the moment -- with sections and tasks and fai classes eg. Which is okay, but it's far beneath the level of coolness provided by Knoppix. And as well, if we get flavours to work almost as well as Knoppix (creating a livecd that autodetects hardware and sets you up in a Linux environment with KDE and Gnome and whatever else, by telling it nothing more than which bits of Debian you want on that livecd), then that makes maintaining Knoppix a lot easier, since half the work is already done.

> With my ideas of Flavours and Derivative Distros, Flavours are Custom > Debians, but Derivative Distros are things like Knoppix which are > derived from Debian but are not policy compliant, and so they can't be > called Custom Debians.

I'm not seeing any difference between "flavour" and "custom Debian" in the above then. I think it's a waste to have words that mean exactly the same thing.

So, using my definitions, the following conclusions are (IMO) true:


andreas tille:

The problem is that we want to get those "Custom Debian Distributions" which where formerly known as "Debian Internal Projects" which are Debian-Jr, Debian-Med, Debian-Edu, Debian-Np, Debian-Lex and others (see my talk once people.d.o is up again) under one common thing. These Custom Distributions use the technique of metapackages and have common goals and try to develop common technologies.

It would be easy to mention these under one common term for an easy reference. In Oslo was a decision to name it "Custom Debian Distribution" and if we try to speak with each other we have to agree about some terms. This thread shows that there is not yet an agreement and this sucks because we have to explain over and over again what we are talking about.


fabian fagetholf:

If some of the people who participated in the Debcamp Custom Distribution BOF (see http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was referenced as one of the driving forces behind the meeting.)

It might be hard, impossible and undesirable to reverse the decision to use the term. I think the term can be correctly understood if you present it as I have in some recent postings to this list:

A subproject is easily understood: it's an organisational structure. Basically, it's a group of people working on a subset of Debian. They coordinate via a web site and in some cases have a special mailing list.

Some subprojects create Custom Debian Distributions for their particular area of interest. Upon installation of the Custom Debian Distribution, you can select between a number of flavors that set some defaults to suit a particular use.

More ideas? Perhaps some of this could be intergrated into the Debian Subproject Howto as soon as some degree of consensus has been reached. (I can't find it right now with people.d.o being inaccessible.)


mako:

Your other posts seems well informed. Subprojects is already defined for us (see http://www.debian.org/devel/ for an example of one place). Debian-NP is clearly a subproject as is Debian-Med and the ["IPv6"] project.

If you apt-get install the subproject-howto you will get something talking only about creating a custom Debian-distribution -- not about creating a subproject for any other sort of work. The folks at the BOF saw a real lack of interaction between the people making custom distributions and we attributed this, in part, to the fact that we didn't have a single concept around which identify and say, "yeah, that person is doing the same thing as me, we should work together." The flavors people were not working with the metadistros people and the subproject people where on their own.

We thought "Custom Debian Distribution" (and a ["custom"] tag in emails to -devel until a list is created) both referenced our relationship to Debian (we're inside) and described what we were trying to do in a way that was not so restrictive that it couldn't refer to multiple technologies but not so broad that it would apply to projects with very different types of goals.

I think we left with the idea that "flavors" or "metadistros" and the like may still describe technologies or methods which one could use to achieve a Custom Distro.

I think this is in line with what AJ, yourself, and others have said -- which is nice. :)

> More ideas? Perhaps some of this could be intergrated into the Debian > Subproject Howto as soon as some degree of consensus has been reached. > (I can't find it right now with people.d.o being inaccessible.)

I think it absolutely should. I also think the HOWTO should be renamed or expanded in scope to bring it into alignment with the consensus that seems to be coalescing around these issues.