Re: Choice of toolkits concerning "typical" vs. Debian Jr. CDD

[Andreas Tille <tillea@rki.de>]

[It was right to move this thread that originally started at
  http://lists.debian.org/debian-jr/2007/04/msg00003.html
 and concerns the way debian-jr meta packages are builded.]

On Tue, 24 Apr 2007, Ben Armstrong wrote:

> > Why?
>
> 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
number.

> 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
idea.

> 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
> users.

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
> support it.

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
CDD-documentation.
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.

Kind regards

       Andreas.

--
http://fam-tille.de