Re: Google Summer of Code 2006
On Thu, 2006-04-20 at 13:02 +0200, Andreas Tille wrote:
> On Thu, 20 Apr 2006, Free Ekanayaka wrote:
> Well, according to the Definition of a CDD at
> http://wiki.debian.org/?CustomDebian
Glad you posted that link. Please forgive my previous ignorance.
> 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.
>
Would a tool that can perform a superset be acceptable? And more
importantly, would you find it fun to work on it? I have unusually wide
technical control of the project (for a company engineer, you know?). So
if there are compromises needed to make the project useful for a wider
pool of users and developers, I'm all for 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.
>
I'll highlight some key flaws in PDK based on what you've said:
We've been primarily focused on maintenance of components (our grouping
mechanism), security (and other general) metadata with an api for
reporting, and the ISO generation problem (including installer). These
have been the riskiest part of project for us, given that we want to
generalize across rpm distros and Debian.
Debtags support isn't what I'd like it to be at the moment, furthermore,
I've not accomplished much yet in the areas of menu and config
customization. Here at Progeny we've delved into meta-package building
as it got to be a real pain to keep rebuilding dcc, but I don't have
anything to show for that yet. There's an internal script that can write
subst-var-include-able depends data, but that alone doesn't make
building metapackages easy.
I'd be tickled pink if I could host code that drives CDD projects in
PDK, and I'd completely understand if you chose to do your own thing.
(Hey, we did. We think our needs were unique, but that isn't so unique.)
> > 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).
There is one possible conflict. I'm hoping to keep PDK in what I call
perpetual beta. As time goes on, the ongoing cost of maintaining an old
distro tends to increase. As time goes on PDK improves, lowering the
cost of maintaining your old stuff.
Having a frozen version of PDK in Debian Stable encourages people to not
use recent PDK and therefore incur higher maintenance costs.
Other than that, I'm not the guy to maintain an official Debian package,
but I'd be happy to support the right person in any way I can.
--
Darrin
Reply to: