Re: Google Summer of Code 2006
|--==> 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
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
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.
>>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
>>:), 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.