|--==> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
