-----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-----
