Re: Pre-BOF CDD ideas
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
> 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
(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.
> pool/ -> <link to the official MDD pool/, since the packages are the
Which is more or less the last suggestion of
> 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.
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-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. ;-))