On Sun, 30 May 2004, Cosimo Alfarano wrote: > 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. In Valencia Free Ekanayaka expressed this in a very illustrative manner as an object model which I tried to summarize in the third paragraph of
http://people.debian.org/~tille/cdd/ch-introduction.en.html (I hope the URL is correct because people.d.o is down - I just mean the introduction section of the CDD paper.) > And since Debian will base itself on CDDs, fully supporting them, there > will be a way to let CDD to release asyncronously from MDD. This is also covered more or less in the updated version of the CDD paper. I think your ideas are a little bit more concrete than it is expressed there and we should settle down with a "way of choice" selected from the proposed ways of different people which I tried to summarize or just find a further one. > /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 > ... Which is more or less the last suggestion of http://people.debian.org/~tille/cdd/ch-todo.en.html#s-new_ways_of_distribution > 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. Exactly. I think I will add your detailed considerations to the doc once I'm settled down from my vacation. > Alternatively: > > /debian/ > pool/ > dist/ > stable/ > unstable/ > testing/ > main/ > <CDD>/ > main/ > contrib/ > binary-<arch>/ > Packages > Release It would be great if these alternatives could be discussed and some conclusion could be found at DebConf4. > 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. If you ask me I'd prefer the first suggestion because I expect much more trouble here. > 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) I have doubt's whether this might be reasonable for large packages. It would only make sense in the way package-xy-common package-xy-flavour1 (depends package-xy-common) package-xy-flavour2 (depends package-xy-common) which also needs the agreement and willingness of the maintainer of package-xy. So I see no big practical use for this package flavours because the above seems to be stupid and needs more maintenance than trying to go with sane configuration solutions. > It's STRONGLY needed that any maintainer will collaborate with the CDD > staff guys and be fair with their decision about bug requests :) Yes. This can be fixed by the CDD-world-domination-issue which was proposed by Enrico. ;-)) Kind regards Andreas.
