[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: let's etch a common way of using debtags for CDDs and beyond!



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19-05-2005 23:04, Sergio Talens-Oliag wrote:
> 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.).

It seems to me that Gatzemeier and I are talking about the same, but
possibly you are not discussing same thing, Sergio (how do you mean this
could save data? Debian already separate l12n into separate packages):

Today, if you want a desktop with daish l12n you need some or all of the
following packages:

idanish
wdanish
miscfiles
mozilla-firefox-locale-da-dk
kde-i18n-da
koffice-i18n-da
openoffice.org-hyphenation-da
mozilla-locale-da
myspell-dictionary-da
aspell-da
gcompris-sound-da
debconf-i18n
icu-locales
gimpprint-locales
util-linux-locales
locales
liblocale-gettext-perl
pennmush-i18n
bibletime-i18n
libi18n-java
libqt3-i18n
wxwin2.4-i18n
sylpheed-i18n
akregator-i18n
k3b-i18n
kile-i18n
xcalendar-i18n

The above list was gathered by searching for 'danish', '-da', '-dk',
'i18n', 'l12n' and 'locale' - and then judging each result manually be
reading the long description.

I don't want all those files hardcoded to a single metagroup. I want
each of them pulled in whenever I need them - that is if I say I want
"danish", "kde" and "system tools" I want international support for the
K3B CD-burner software even if it is only suggested by k3b itself.


>>>  - How would you make one of your tasks conflict with a package?

Using Tag-Conflicts:

The current skolelinux release bets on KDE. Such choice could ideally be
expressed as the following (deliberately oversimplified):

Tag-Depends: suite::kde
Tag-Recommends: use::learning
Tag-Conflicts: suite::gnome

The reason for recommending use::learning instead of depending is to
allow dropping gnome-related learning tools.


>>>  - How are you going to distribute the pre-seedings and the scripts used
>>>to configure and update your customizations?

Imagine a Debian package "tweaks" with a big bunch of pre-seeding
answers and idempotent (read: cfengine) scripts - a little like
autoconf-archive but organized in OWL classes shared with debtags and FAI.

Then imagine your cddtk package enhanced, so that tagging not only is
applied to what packages are included, but also what tweaks should be
applied before (pre-seeding) and after (cfengine) installation.

So, from the special "CDD control-file" in the CDD source (which
possibly also contains custom logo and artwork, local sources.list
referencing unofficial packages, local tweaks and a local debtags
override-file), cddtk generates a CDD metapackage: a plain vanilla
control-file with package package dependencies, all relevant tweaks
copied from the tweaks package, and pre- and postinst scripts to
properly apply the tweaks (and reapply them each time any package is
messed with!).


- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjedTn7DbMsAkQLgRAl9fAKCnL4eCuIT73CRx4db7xIRIIZI5zQCcCMwi
PyuRkyu0+1OWbl7JguMQZrQ=
=TdOC
-----END PGP SIGNATURE-----



Reply to: