El Wed, May 18, 2005 at 04:15:04PM +0200, Jonas Smedegaard va escriure:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 18-05-2005 01:25, Sergio Talens-Oliag wrote:
>
> > I've read all your mail and I don't see why it has to be based on debtags. I
> > see the interest on debtags as a simple and powerful way to categorize
> > packages, but what is the advantage of using debtags instead of the
> > description file I've proposed?
> >
> > I feel that the contol-like syntax is easier to use by developers, as they
> > are familiar with it and, unless I'm missing something, it is much easier to
> > declare package dependencies using the control file format (it has the same
> > syntax that the rest of the Debian system uses).
>
> Package dependencies are in some situations too strict.
>
> Example: Woody-based Skolelinux depends on KDE 2.x packages, so breaks
> if applied to Sarge.
And? I believe that it is right to break if the dependecies are versioned,
that mean that you need/want a concrete version, and you should use
different tasks for a Woody based CDD than for a Sarge based one (that can
be included on the same CDD description package, BTW).
If you don't have a versioned dependency it shouldn't break, the only thing
I see here is the case of a package being renamed, and then adding a tag is
the same as adding or modifying a task description for a given distribution,
but that's part of the CDD mainteinance in the same way as a new version of
a package can break an older package that depends on it.
> If instead Skolelinux had been able to (and interested in) using a
> debtags approach instead, they could have expressed dependency on "all
> official Debian packages tagged as suite::kde".
Hmm, not sure if I would ever like to do that, but assuming that this is
equivalent to the use of something like debian-edu::kde, I still don't see
the advantage to my approach, somebody has to update the tags for my CDD,
which is equivalent to updating the description.
> What actually happened was that the Skolelinux metapackage(s) got
> adopted as official Debian packages, but then caused problems shifting
> to newer KDE because it depended on the old KDE packages. The Skolelinux
> metapackage(s) then was changed to only recommend instead of depend, but
> that only avoids the metapackage breaking other parts of Debian, the
> metapackage itself is still practically broken until upgraded.
Have you read my proposal? It is available on:
http://people.debian.org/~sto/cddtk/cddtool.html
I don't plan to use metapackages, my idea is to
use only one package that depends on the cddtool runtime and provides a
description of the CDD. That package only contains the data needed to
install the different tasks or flavours of the CDD, but it is not a
metapackage, so the dependency problems on the archive are avoided.
As I've said before, I'm not against debtags, but it's use for package
selection leaves a lot of things out:
- How would you make one of your tasks conflict with a package?
- How are you going to distribute the pre-seedings and the scripts used to
configure and update your customizations?
Keep in mind that my idea with the cddtk proposal is to have a way to define
a full CDD in one place.
Anyway, I believe that a good improvement to my control file syntax is to
add a new set of control fields to define dependencies in terms of tags,
maybe being able to include on a task definition things like:
Tag-Depend: mycdd::desktop-std, mycdd::net-base, mycdd::devel
Tag-Recommends: mycdd::desktop-full
Tag-Suggests: mycdd::network-extras
to declare dependency relationships and a field like:
Tagfile: file_with_tags_for_mycdd
to be able to use a tagfile distributed with our cdd-description besides the
system one.
That way the cdd-tool would support your way of declare that packages belong
to a CDD task while keeping the posibility of using the already available
Fields... what do you think?
> CDDs could benefit from the FAI classes-based cfengine (and other)
> scripts being packaged in a separate package, and the tweaks needed by
> each CDD slowly added to that package.
So the idea is to use and improve the configuration scripts found in FAI,
perfect, I believe it is a good idea, I'll look at them.
> and FAI join forces in maintaining what was initially my plan with the
> "tweaks" Alioth project (which I have been all too slow at starting), we
> can help the package maintainers and Debian in general to see what areas
> needs most unofficial tweaking and thus is in most need of official
> support through debconf or other means.
I'm getting to the point that I believe that debconf is great for the
initial installation but it is not what for mainteinance.
The debconf usage works for initial installations and if you reinstall from
scratch, but not being able to change defaults on debconf answers
automatically makes it less attractive for upgrades, as my idea is that an
upgrade of an installed distribution that has not been touched by the user
should be equal to a new installation of the new system, and that is not
going to be true if I change the debconf defaults, as the upgrade will leave
the old values in place...
> The best organized and largest pool of configuration tweaking scripts to
> use as common base is IMHO the one found in FAI - and hopefully soon
> provided in a separate Debian package not depending on netbootable
> kernel, NFS and other stuff required to setup a fullblown FAI environment.
Are there any plans to have this package ready soon? Is somebody working on
it?
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature