Hi Jonas, hi all, On Do 26 Jan 2012 11:58:55 CET Jonas Smedegaard wrote:
So, my opinion is that without implementing the blending mechanism within Debian policy itself (and that is also: within dpkg itself), we may possibly stall here for longer.It is the other way around: Debian Policy only reflects what is already consensus in Debian, so changing policy requires to first create consensus and then - after the fact - document it in Debian Policy.
Good point, thanks for giving this more light.
So, my proposal is: * let Debian blends become a real element of the Debian package system * that is: implement in dpkg three options: - Option 1: --blend=<blend-name> - Option 2: --unblend - Option 3: --init-blend (or --native2blend or similar)What does the above mean? Is it flags tied to a source package or to a binary package or to a system? If the latter then I suspect that you may really mean APT, not DPKG. In other words, does it imply that only a single blend can be applied?
I am talking about each single Debian package. Not the whole system. And every package in this model can be in non-blended mode or in blend mode for _one_ blend.
Example: if we install d-e-c, we have to tweak apache2 configuration. For this we would set apache2 into ,,edu'' blend mode. If apache2 is in ,,edu'' blend mode it cannot be set into ,,gis'' blend mode etc. You can unblend apache2 and blend it with some other blend only then.
If really you are trying to document debathena rebranded as blends then please say so. If so it also seems sensible to involve the developers of debathena - either by discussing with them first to understand why their package(s) live only outside of Debian, not (tried to become) official part of it, or invite them to this very discussion directly.
The idea proposed here was first. Then I re-read #311188 and stumbled over Marius's posting and took a closer look. I was astonished by some similarities. And it was also clear that they are doing it outside of Debian and that they do the same stuff as d-e-c. The install package-A and then config-package-X and config-package X overrides files in package-A.
* This blending process may do the following... **of course, the below has to become a legal part of Debian now...** - create copies of existing configuration file(s) <conf>.d folders in <package-name> /etc/<folder>/<cf-file> -> /etc/<folder>/<cf-file>.dpkg-native /etc/<folder>/<cf-folder>.d -> /etc/<folder>/<cf-folder>.d.dpkg-native - divert the original configuration file and <conf>.d folder names to the corresponding files/folders in the /etc/blend/edu namespace. - tag the affected package (maybe in /var/lib/dpkg/info) as blendedAbove seems like the central piece of where we are stalled at the moment regarding nedding-different-config-than-package-offers: The way forward is not to legalize mechanisms currently violates Policy, but to work on refining said mechanisms to a point where the Debian community is convinced that it is sane to do, and _then_ document the fact in Policy.
This sounds like a senible way of progressing on this. However, what exactly do _you_ mean by ,,refining said mechanisms'' (not sure what the said mechanisms are and how to refine those).
I believe dpkg does not reliably support diverting conffiles. That particular piece can be worked on (or at least investigated and documented more clearly) independently from this grand plan.
^^^^^^^^^^^^The above is what you refer to as refining, I guess? So that would be dpkg development then.
* Alternatively, if the configuration files of a package shall not be replaced by d-e-c then we also find a dpkg --init-blend <package-name> command call useful (or --native2blend or --clone-native2blend or ...). -> install a copy of the original package's config files from /etc/<config-folder> -> /etc/blend/edu/<config-folder> After this, configuration files provided by the package maintainer can be manipulated with cfengine (within /etc/blend/edu/<config-folder>, of course.Above seems to me as a reinvention of dpkg-divert. If you feel that is a sensible way forward (I don't) then it seems to me that you need not reach concensus for the whole grand plan in order to improve this piece: you can discuss that with dpkg developers directly.
In Debian Edu we currently follow two strategies: 1) provide our (D-E) own+complete config file for some Debian package 2) apply cfengine of D-E to some non-D-E config files in some Debian packageBoth ways of tweaking config files should be managable with a proposed model. Actually the first is pretty much alike to dpkg-divert and it probably can be a wrapper around dpkg-divert that handles the blending and unblending process.
The second approach is rather creating a ready-for-blending-with-cfengine-copy of the orginal config files, move the original's out of the way (.dpkg-native), replace the copied files by symlinks and then tweak the copied files with cfengine (or puppet or ...).
My basic question at this point becomes this: does such an approach have a chance to be supported and refined by the people being interested in blends, or do people who have to deal with blends deny such an approach right away for reasons A-B-C-etc. It does not make sense enrolling people outside the group with definite use case into something that is not supported by the people with the use case themselves.
Thanks for any input you have! Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
Attachment:
pgpuDlWD8kS2t.pgp
Description: Digitale PGP-Unterschrift