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
> 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.
Reply to: