Re: let's etch a common way of using debtags for CDDs and beyond!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24-05-2005 02:33, Tzafrir Cohen wrote:
> On Tue, May 24, 2005 at 12:39:24AM +0200, Jonas Smedegaard wrote:
>
>
>>>And you don't want to call those tweaks "packages" because?
>>>Packages can be home-made. They don't have to come from an official
>>>Debian archive.
>>
>>When you hack a configuration file officially in a Debian package, it is
>>done in "maintainer scripts", typically "postinst", and sometimes tied
>>to a debconf-based question. Such maintainer script makes sense only as
>>part of that package, not as an independent package.
>>
>>Tweaks are "maintainer scripts" for "CDD maintainers". As such they make
>>sense as part of the CDD, not as independent packages.
>
>
> Why not call them independent packages?
Why do you ask the question to an already written answer?
Let me guess... Maybe you think of "CDD" as metapackages more than
distributions. Try if the following better qualifies as an answer to
your question:
Tweaks are "maintainer scripts" for "distributions based on
distributions". As such they make sense as part of the "distribution
based on a distribution", not as independent package.
I really want to understand your question, not play games with you. But
I don't understand what you mean by repeating something I thought I just
clarified. So please try again - and use more words this time, please :-)
> As mentioned up this thread, the problem with the d-i approach, and also
> with cfgengine and alike, that those work for install-time, but won't
> work for later upgrades.
The problem is not the ways hacks are applied, but _when_ they are applied.
I guess that the "d-i approach" you talk about is debconf preseeding. If
applied only at install time then yes, only at install time the changes
are assured. But as long as the package asks the exact same questions it
can be forcefully fed the exact same response, so the issue is then to
preseed not only on installs but also on upgrades.
The CFEngine script I wrote (and is quoted further down) works similarly
but for packages that does not ask the question I want: It is written to
apply sanely again and again, for as long as the config file stays in
the same format and requires the same kind of changes.
When some day our assumptions about the package we hack on changes,
applying the hack *must* fail. That is the case with preseeding (when
there is no longer the exact same set of possible answers to the exact
same question) and with CFEngine tweaks (when the hints looked for no
longer exists - as when file format change from INI-style to XML-style).
By comparison, a classical diff is designed to fail when the surrounding
couple of lines do not match (which is too vague in many situations).
simple copying (as is currently done in the package I filed a bugreport
against - quoted below) the hack is always applied even if it no longer
makes sense.
CDDtk documentation seems to realize this issue, and moves in the
direction of applying hacks each time packages are worked on instead of
only at install.
> Also consider the "source package" approach:
> cdd-tool will create the appropriate binary packages at build time.
This is *exactly* why I believe it makes most sense to keep CDD control
info as a "source package" only: The generated output applies to a
specific pool of packages as a specific point in time. Each time a
single one of those packages in the pool changes, the CDD metapackage
may need recompilation.
The package dependency info of CDD metapackages relates to Releases.gz
more than to the actual packages.
It makes sense to generate package dependencies each time you create a
CDD snapshot CD/DVD/USB-stick/whatever. It only makes sense to apply
those package dependencies as a classic metapackage if the metapackage
is maintained and updated each time the set of packages change (which is
alot more often than the reason for recompiling a standard package:
"each time there is major changes to dependent libraries").
> When working on our Rapid, I originally put many things in our custom
> udeb. But it only took me one release to see that whatever is configured
> there won't be applied when people will upgrade packages.
If your package selection was done through debtags (and an updated
selection was applied as part of your "dist-upgrade"), and you had used
debconf preseeding when possible and CFEngine for remaining config
hacking (and both was applied not only at install time but also at
upgrades) then I bet your problems would have been minimal!!!
>>>Can you provide an example of such a tweak that cannot be expressed as a
>>>debian package?
>>
>>Here:
>>http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/tweaks/oldtweaks/oldtweaks/gconf/desktop-profiles-support.cf?cvsroot=tweaks
>>
>>It is part of a proposed fix for this recent bug:
>>http://bugs.debian.org/309871
>>
>
>
> Yet another chance to say:
>
> "CGonf bad, Elektra good" (at least from package maintainers
> perspective). This is really a flaw of GConf. However in there you edit
> config files under $HOME, which is not something root should do, IMHO.
Have you ever maintained a software package and realized how difficult
it is to convince upstream to work differently than they want
themselves? That is what you dream of doing to *all* software packages
in Debian, when you dream about Elektra.
Sure, GConf is close to impossible to maintain sanely - because it was
designed in a way not very friendly to distributors, and thus even more
unfriendly to CDDs.
Let's look at the possible approaches to ugly things like GConf:
Hacking:
1) Avoid all code using this config
2) Use defaults
3) Hack config here&now
Tweaking (adapt configs both distro- and admin-friendly):
4) Hack config idempotently
5) Use idempotent config-tool provided by package maintainer
6) Use idempotent config-tool provided by author
Programming (mess with binary packages/code):
7) Repackage to unofficially add config-tool
8) Patch code to behave more sanely by itself
9) Have package maintainer patch code to handle config sane
10) Have author (re)write code so it handles config sane
Package (de)selection is 1.
Applying diffs is 3.
Copying is 3.
CFEngine scripts (done badly) is 3.
CFEngine scripts (done properly) is 4.
Debconf preseeding is 5 or 7 - but for small sets of choices only, not
for cases like GConf.
CFG is 4-7 - also for cases like GConf.
Elektra is 8-10.
The typical approaches of CDDs today are 1-3, 5 and 7-8.
What works is to use only 4-10, and work towards only needing 5-10.
The only thing above 4 that can be applied outside of the mother distro
(Debian) is 7-8, and only resource-heavy organisations like Ubuntu can
really do that (and be expected to also maintain it over time!).
CFG can be applied as 4 (if including the CFG helper tools as unofficial
packages until included in Debian), so we can start working on that
right now, even before Debian has realized its potential.
Elektra is out of our reach as CDD developers - but that shouldn't stop
us from dreaming about it and convincing other groups higher up in the
food chain to implement it.
- Jonas
- --
* 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
iD8DBQFClEj/n7DbMsAkQLgRAiCFAKCRS0zCfSEAqAhna2VqRrjAL77CfgCffMri
eNtm1j8UtXk6HA9rzUYeqaA=
=EmD6
-----END PGP SIGNATURE-----
Reply to: