|--==> Andreas Tille writes: AT> On Thu, 20 Apr 2006, Free Ekanayaka wrote: >>Well, I think that the force of PDK is that is a rather general and >>flexible tool, which can be used both to generate fully >>Debian-contained CDDs,
AT> No doubt about this - I've read the description, but CDD has more goals AT> than just creating CDs. Definitely, PDK could be just a tool for those goals, and I think it fits. If you we limit our scope to full-Debian CDDs, which contain only official Debian packages and are released when Debian is released, probably PDK is overkill, as its main advantage IMO is to effectively address the problem of having different release schedules and development phases than Debian. However if you take into the scope even CDD developed by third parties (and it's becoming more and more common), for supporting special groups of customers, then you definitely need a tool like PDK, as in real-like you'll definitely need your own packages and releases. As PDK can handle both scenarios, I think it is worth to consider it as a possible standard too for CDD creation and maintainance. I think the arguments in its favour is that is already rather mature and well designed, and it's fully free software too, so if we can change it if needed (as I'm currently doing). >>which are released when Debian is released, and >>"independent" derivatives too, where external means that 1) there >>might be additional packages which are not included in Debian AT> ... so we would leave the CDD area (which is mainly my point). We have AT> no control over the quality of this stuff. Mmh, of course Debian will guarantee only the quality of plain CDDs (or internal projects) where all packages come from Debian, and releases are synced with Debian releases. Third parties developing CDDs with external packages and different release schedules, will have to take care of them. As I said PDK, can fit both cases. >>2) they >>have a different release schedule than Debian. So it's a matter of how >>you use it.. AT> ... and how you define the noun "Custom Debian Distribution". (Yes, AT> I know the noun is and was missleading and I hate that I agreed to the AT> name change from "Debian _internal_ projects".) I don't know, maybe we could talk about internal CDDs (completely made inside Debian) and third party CDDs.. AT> So nothing against PDK but it will probably not work AT> for CDD development. For instance I do not see a way to make use of AT> Debtags in PDK which I would really like to see in CDD tools. >> >>Actually there are plans to add support for it (I suggested it myself >>[0]:), and it would be relatively easy. 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. The fact that PDK allows more possibilities and third party CDDs, doesn't mean that you can't make internal CDDs with it.. 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. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
