Re: let's etch a common way of using debtags for CDDs and beyond!
Hello,
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?
AFAIK I know for example no sure way in debian to have all the relevant
localized packages automaticly included at the moment. Special language
package lists may not (and probably shouldn't) contain localization packages
for packages not in the cdd scope (but included in debian and subsequently
installed) or simply be be outdated. Resulting in users installing software
and being left with non-localized software.
Dependency declaration based on tags may change that. Apt (or a more
appropriate layer) may narrow down or widen the selection based on language
tags as desired (configured elsewhere), and the dependecies could still be
checked and fulfilled based upon a debtag query defined in the control files.
> > > 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).
Right. The syntax should be the same.
> 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.
The advantage should be there as soon as you can start to include usefull tags
in your query like language specifics, laptop/desktop specifcs etc. that you
don't need to update youself only.
> 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?
Exactly. I think the combination is a good proposal. With a nice syntax it
might even be adopted for the other control files later.
> 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...
I agree, if you are interested to look at it from other angles you may read
http://freedesktop.org/Software/CFG . The XML and GUI stuff might not be of
interest here but maybe the ideas about debconf integration or the per
setting config handling functionality based on multi-level defaults.
With the Cfg-Scripts you are proposing to kind of making the debconf system
stackable, right?
Regards,
Christian
Reply to: