Re: Google Summer of Code 2006
|--==> Andreas Tille writes:
AT> On Thu, 20 Apr 2006, Free Ekanayaka wrote:
>>Definitely, PDK could be just a tool for those goals, and I think it
>>fits.
AT> Perhaps you dived deeper into the details than I. I had only a some
AT> minutes view onto the web page.
Yes, the web documentation is not very well written and a bit out of
date at times.
>>However if you take into the scope even CDD developed by third parties
>>(and it's becoming more and more common),
AT> Well, according to the Definition of a CDD at
AT> http://wiki.debian.org/?CustomDebian
AT> something *like* a CDD developed by third parties is actually no CDD.
AT> I do not say that something is wrong with an external CDD-like thing,
AT> but I would love if we stick to our nomination to avoid confusion.
AT> It is completely OK if somebody outside adopts *some* main ideas from
AT> the CDD effort but one of the main ideas - to make Debian a better
AT> system for any purpose - can hardly be fulfilled by things done outside.
I see your point. Maybe we should update the wiki then, and talk about
"internal" and "external" CDDs (or whatever naming we prefer) with
respect to Debian. The list at the bottom of the wiki includes, for
example, both projects like Debian Junior and Debian Med, which I
think are fully "internal" CDDs, and others like Skolelinux Lliurex
and A/DeMuDi, which as far as I can tell are "external" CDDs as the
ship some packages which are not in Debian (e.g. the ones holding
customization data, or rebuilds of official packages) and have
different release schedules.
>>I don't know, maybe we could talk about internal CDDs (completely made
>>inside Debian) and third party CDDs..
AT> Perhaps we should go for another "name change" and put the internal
AT> in the name of the beast. I have heard so much confusion and my guess
AT> is that more than 50% of subscribers to this list did not noticed this
AT> special feature (which also does not hurd, because finally we work on
AT> the same goal to support our users). But IMHO staying inside is
AT> "the right way" (TM) and it's time to stress this point again (I did
AT> not so for this year and DebConf is approaching so this should be
AT> said again. ;-)
Well, I definitely agree that being all "internal" would be the ideal
solution and "the right way". However in the real world this is not
possible, especially if you are delivering a CDD as product to some
customer. Maybe you need to see your patch applied in some package,
and the official maintainer is slow or busy or simply he thinks
different than you: in such a case you are compelled to build your own
version of that package. Or maybe you have a deadline and you can't
wait for the next Debian release. This doesn't necessary mean that you
are "forking", at least if you do so you should strive to get you
changes eventually integrated back to Debian. At least this is what I
found myself to do.
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.
AT> ^^^^
AT> There are more than one goal and perhaps my sentence was not precise
AT> enough: We leave the scope of the definition.
Yes, what I meant is that, technically speaking, you can effectively
use PDK to build "internal" CDDs, without going outside 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..
AT> If it is more than a ISO-builder for a customized installation CD-ROM
AT> that contains Debian packages with adopted configuration, but also
AT> can handle Dabtags (it's nice that you supported this) build meta
AT> packages, can care for user menus etc than it's fine.
As I said, it might not yet implement any feature we needs, but the
code is there, and I think is a very good starting point.
>>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.
AT> PDK inside Debian would be a precondition for me to agree that it is
AT> able to build a CDD (according to the current definition).
For sure.
Cheers,
Free
Reply to: