Pre-BOF CDD ideas
Here's a small draft of my own ideas about CDDs and the future of
Debian.
I've stolen the subtitle from Enricos/Mako's talk title :)
Only rough ideas.
All this stuff have to be discussed during a (unofficial) BOF about CDD
we'll organize in the next days. I hope on monday, after the CDD talk, a
small BOF might be taken.
Probably these ideas are very revolutionary respect to the really
conservatory trend of Debian, but we all think we really need them
arranged in some way (the best one) so let's start working on it now to
have it usable on the next (non sarge :) stable release.
I throw the stone :) any good ideas are really really well accepted.
cheers,
c.
DRAFT DRAFT DRAFT DRAFT DRAFT
Title: my personal view of the future of Debian
Subtitle: how Custom Debian Distribution can change the world
o Debian Distrubution vs. Custom Debian Distribution
The idea is to have a main Debian flavour 'Main Debian Distribution'
(MDD), and a lots of different special targeted flavours 'Custom
Debian Distribution' (CDD), living togheter.
A secondary (but not less important) target is to modify views that
users have of Debian, in the near future I hope we'll have inside the
Debian project:
- main Distruibution, the Debian we currently know
- custom Distruibutons, as a particular views of Debian:
the main Distribution filtered through the lens of particular
users.
Substantially: Debian as a CDD itself.
o Stable, Testing and Unstable: How to handle the gap and release CDDs
quickly.
Sometimes CDD has release needings completly differents from the main
debian upstream, of which release cycles make users complain more and
more frequently.
Custom Distributions (in general and CDD specificately) need to release
updates on a 6 month basis circa.
And since Debian will base itself on CDDs, fully supporting them, there
will be a way to let CDD to release asyncronously from MDD.
Testing ditribution virtualized per CDD preferences
- Particular views of the actual Testing Distro filtered to obtain
a new <CDD>-Testing depending of the needing of the CDD.
In this way we can have the official Testing, with all the tests
applied, and special Testing per CDD, for example letting CDDs
choose to not support some arch.
It's not supposed to change tests on BTS and youngness.
- Example: filter the testing-excuses file and creating a new output
with all packages testing would contain if architecture X wasn't in.
(usefull if a particular packages is blocked in unstable because it
cannot compile under arch X, but actually CDD isn't interested in
arch X binaries)
How a CDD might be view by the users?
http://ftp.debian.org/debian-<CDD>/
and the archive may change to:
/debian/
/debian-<CDD>/
pool/ -> <link to the official MDD pool/, since the packages are the
same>
dist/
stable/
unstable/
testing/
main/
contrib/
binary-<arch>/
Packages
Release
...
In this way it's clear that CDD is a part of Debian, and not only
something related to Debian, and it compatible with the existent archive
structure.
Pro: lets CDDs having their own stable/testing/unstable distro, produced
in the some way of MDD, but with asyncronously and with slightly
different rules.
Pro: it uses the same .deb in /debian/, got by symlinks, no space
wasted.
Contra: adds a new brench to archive, probably adding some mirroring
problem.
Alternatively:
/debian/
pool/
dist/
stable/
unstable/
testing/
main/
<CDD>/
main/
contrib/
binary-<arch>/
Packages
Release
Pro: it uses /debian/ tree, no mirroring problem created
Contra: in this case there will be only one version of a CDD, considered
a <distro> for the archive purpouses, similarly as stable/unstable/testing
distro are. All developing version have to be tested somewhere else, and
that's bad IMHO.
Probably sections (main/contrib/non-free) may be changed to CDD flavours
(like ( med-bio -> dist/med/bio/ ), but I'm not sure about policy.
o patches, Debconf, cfengine and the package Customization Problem
AKA: We need collaboration from all the Debian Cumunity
(actually this issue has been discussed today by the guys who remained
here in Porto Alegre and I wasn't among them, a BOF will be tomorrow eve)
Since a CDD is '100% Debian inside', no external sources can be used,
and all the work have to flow more fairly as possibile (no hijacking,
'you-do-not-accept-my-patch-NMUs', and so on).
So how handle the special configuration needings (a very main goal of a
CDD!) and patches?
The configuration issue has been discussed very deeply, and the only way
came out is use debconf to ask questions with priorities and preseeding,
and using cfengine (or similar tools) to modify conffiles.
In this way, a CDD in needing of something can use Debian BTS to send
patches, filing bugs or asking for a 'question' to be added to debconf.
No possibility to use an external source, but probably an upload to
experimental of the 'special' package might be done, with the only
intents of having it in the virtualized Packages and let people test it,
so that the maintainer can decide to adopt the proposed changes.
I'm talking of a special flavour/patched version of package X, and must
be done in the fairest manner possible (no versioning problem, no any
sort of hijacking, and so)
It's STRONGLY needed that any maintainer will collaborate with the CDD
staff guys and be fair with their decision about bug requests :)
--
Cosimo Alfarano, kalfa at {bononia.it,debian.org,cs.unibo.it}
0DBD 8FCC 4F6B 8D41 8F43 63A1 E43B 153C CB46 7E27
foaf://www.bononia.it/~kalfa/foaf.rdf
Reply to: