Re: Google Summer of Code 2006
On Thu, 20 Apr 2006, Free Ekanayaka wrote:
Definitely, PDK could be just a tool for those goals, and I think it
fits.
Perhaps you dived deeper into the details than I. I had only a some
minutes view onto the web page.
However if you take into the scope even CDD developed by third parties
(and it's becoming more and more common),
Well, according to the Definition of a CDD at
http://wiki.debian.org/?CustomDebian
something *like* a CDD developed by third parties is actually no CDD.
I do not say that something is wrong with an external CDD-like thing,
but I would love if we stick to our nomination to avoid confusion.
It is completely OK if somebody outside adopts *some* main ideas from
the CDD effort but one of the main ideas - to make Debian a better
system for any purpose - can hardly be fulfilled by things done outside.
I don't know, maybe we could talk about internal CDDs (completely made
inside Debian) and third party CDDs..
Perhaps we should go for another "name change" and put the internal
in the name of the beast. I have heard so much confusion and my guess
is that more than 50% of subscribers to this list did not noticed this
special feature (which also does not hurd, because finally we work on
the same goal to support our users). But IMHO staying inside is
"the right way" (TM) and it's time to stress this point again (I did
not so for this year and DebConf is approaching so this should be
said again. ;-)
AT> Which would be great and as I said the tool itself sounds very cool
AT> and we might be able to adopt things (or port it to a Debian internal
AT> tool) but we just leave the goal we defined for a CDD.
I don't see why we leave that goal of plain CDDs.
^^^^
There are more than one goal and perhaps my sentence was not precise
enough: We leave the scope of the definition.
The fact that PDK
allows more possibilities and third party CDDs, doesn't mean that you
can't make internal CDDs with it..
If it is more than a ISO-builder for a customized installation CD-ROM
that contains Debian packages with adopted configuration, but also
can handle Dabtags (it's nice that you supported this) build meta
packages, can care for user menus etc than it's fine.
Of course, as PDK reaches a production-ready stage, I'd like it to see
it in Debian, and I can maintain it if need.
PDK inside Debian would be a precondition for me to agree that it is
able to build a CDD (according to the current definition).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: