El Thu, May 19, 2005 at 06:03:18PM +0200, C. Gatzemeier va escriure: > > 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. Yes, a good way of doing that in Debian would be great, it can be done on a CDD, but a general system would be better in general. In fact I've always thought that having a way to do this in way that allows developers to split a package separating the binary dependant files from the data would be great. Such a system could be used to reduce the archive size (all shared data is only stored once for each package) and also would allow to update data without the need to recompile the package (that could be great to update translations, replace images for branding on Dervied distributions, etc.). > > 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. Good, then is the proposed syntax enough or do I you think that we need to include or modify something? I don't plan to use that now, but adding the Fields on the file parser and documenting it on the cddtool proposal could be a good idea before it gets lost on the mail archive... ;) > 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? Well, more or less yes, that was one of the ideas we talked about on the CDD DevCamp. -- 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