Re: Choice of toolkits concerning "typical" vs. Debian Jr. CDD
- To: Custom Debian Distributions <email@example.com>
- Cc: Debian Junior <firstname.lastname@example.org>
- Subject: Re: Choice of toolkits concerning "typical" vs. Debian Jr. CDD
- From: Andreas Tille <email@example.com>
- Date: Tue, 24 Apr 2007 15:02:21 +0200 (CEST)
- Message-id: <Pine.LNX.4.62.0704241414050.27616@wr-linux02>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <Pine.LNX.4.62.0704102128510.3302@wr-linux02> <firstname.lastname@example.org> <Pine.LNX.4.62.0704102218390.3302@wr-linux02> <email@example.com>
[It was right to move this thread that originally started at
and concerns the way debian-jr meta packages are builded.]
On Tue, 24 Apr 2007, Ben Armstrong wrote:
You asked here why I say metapackages work well for me. I don't really
know what to say.
Well, my question was rather: Why you prefer _separate_ meta packages
and not one _release_ _set_ of meta packages with one common version
I simply have not had any trouble with them that
seemed worth the effort to change. At various times in the project I
thought a change was needed, but at this time it works well enough, is
simple to look after, and none of my users are telling me "look, this
really doesn't work well at all". So, why not?
I'm currently also in favour of the meta packages approach even if
I definitely want to add some DebTags related approach. But I do not
see the latter as a replacement for DebTags. The rationale why I
think that meta packages should be builded using a common tool is
that you can easily adopt other techniques (for instance DebTags)
or can profit from menu building stuff or things like that.
Precisely. Observing my own family,
So you are not "big brother" but "big father". ;-))
I can choose
some "safe" defaults for the starting point, but I would rather leave as
many options open as possible,
and that means per-user customization.
Well, I'm just quoting the parts of your paragraph that seem most
important to me. I'm sure that we will not be able to deliver a
complete system that the local admin will not touch any more. The
idea is to give the local admin good chances to need not repeat the
work other local admins of a CDD over and over by setting reasonable
defaults. I see no point in your arguing that is against this
Debian Jr.: a home system with a default package selection and some
initial default child's accounts settings which then are modified by
the administrator to suit their child users as they grow according to
their own tastes and values.
I fully Agree here.
A "typical" CDD: a Debian system devoted to some particular purpose,
tailored by the CDD project to meet those particular needs, where the
choices of the CDD project will meet the majority of the needs of their
My practice shows that "there is no such majority" and even if
you think that people are doing exactly the same job they have
different preferences. In short: I fail to see the difference
between the two characterisations.
It is not that Debian Jr. does not qualify as a CDD, but I actively
avoid making choices for the children and administrators as much as
possible, preferring instead to keep them well informed about issues
and equip them with suggestions for solving their own problems rather
than solving them for them. So yes, there is a subtle difference of
philosophy here that calls for a difference choice in technology to
Well, currently the existing difference in "choice of technology"
is building single independent meta packages with duplicated code
versus building a set of meta packages. IMHO this difference is
completely orthogonal to the difference you tried to explain - at
least I fail completely to see it.
IMHO there are two reasons:
1. If all CDDs have so different needs that there is no chance to
base them on a common toolkit, it makes no sense to continue
development of cdd-dev.
That is a large extrapolation from my argument. I have singled out
Debian Jr. as different not because I believe *all* CDDs have such
different needs, but because of a difference of philosophy that has
grown in my mind over the past seven years to the point where I now
recognize that somehow my project doesn't quite fit the mold.
Well, it is really a large extrapolation but I seriousely wonder whether
my approach to a common set of tools was not adopted by any other CDD
since nearly five years. I did several efforts adopted tools Debian-Edu
seem to depend on (which really enhanced my own debian-med packages),
prepared building stuff for Debian-Jr and wrote extensively on the
I hope that this does not sound like whining that nobody cares about
my stuff, but I just wonder whether it is worth the effort or whether
I just have some missconception (which would be no problem for me -
I just want to do some reality check).
- a live CD / install CD, which most CDDs have and which we are
currently implementing built on the work of the Debian-live project;
Well, this is a good hint. I would like to have a toolkit that
enable the CDD-maintainer (me) to easily set up thus CD ISOs
without learning how Debian-live (or some other alternatives)
works. I'm personally competely in the dark how to decide for
a working toolkit to build install media or something like that
and the funny thing is that we did not managed to develop a
common tool inside the CDD scope what everybody needs. So we
reinvent the wheel for every CDD - which is what I want to avoid.
I personally really want to concentrate onto including *medical*
stuff and not want to spent my time to find out how to build some
ISO images to learn 3 months later that somebody else developed
somethings where you can build ISO images even better.
I could go on. With little to no technology here that is specific to
CDDs, the project does very well to adhere to the core ideals of a CDD.
Well, the core ideals are fine and I have no doubt about this.
My concern is: Is it possible to share as much technique as
possible by turning ideals into code or is it enough to
share the ideals and do the coding in every CDD separately?
This is an honest question because if I would find a reasonable
answer to this question I would probably stop spending my time
in trying to generalize what I'm doing for Debian-Med.
In summary, neither applies. Concerning 2, I am sure quite a number of
CDDs could use cdd-dev. I am not sure why they have not. There does
seem to be quite a lot of re-inventing of the wheel happening here, but
this is not altogether unsual for Debian in general.
Yes. The problem is for me: Why should I make efforts to avoid
that others reinvent the wheel if they do it anyway? I could
save this time to reinvent those bits that Debian-Med is missing
what I hoped others would introduce in a common toolset.
How and why any
given package gets attention while other, arguably better designed
packages get relegated to the sidelines continues to be a mystery to
me. It seems to depend not only on technical excellence, but also on
good fortune and the whims and fashions of the day.
Well, my guess would be that "never change a running system" is
a big argument contra switching form the existing system to
cdd-dev. I wouldn't think that this argument is insane but
I do not want to make myself a Don Quijote and ask people to
stop things they do for valid reasons.
Concerning 1, I support your efforts with cdd-dev and wish you well.
I know you put some effort into the initial cdd-dev conversion of the
Jr. metapackages and am sorry we never did use it, but what at the
time you did it was probably 90% neglect on my part and 10% doubt
about whether the toolkit was going to truly meet our needs has now
been dramatically reversed: Debian Jr. is no longer being neglected,
and I am now firmly resolved that the technical choices we have made
are sufficient for our needs.
Well, I continue to fail in seeing the difference in the result (just
meta packages) when doing the single package approach or just using
cdd-dev that needs less editing and IMHO less work, but it is not
my goal to stop anybody from doing what he prefers to do.