Hi, NB! Please do not cc me - I am subscribed to both d-blends@ and the bugreport. More info at http://www.debian.org/MailingLists/#codeofconduct On 12-01-26 at 12:24pm, Mike Gabriel wrote: > 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. Thanks for the clarification. > 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. So if "edu" wants to tweak a single option and "gis" wants to tweak a single _other_ option, those two tweaks cannot both be applied if "edu" and "gis" both use your proposed mechanism? Seems bad design to make blends mutually exclusive at the core of the blend mechanism. Sure it might be sensible for one blend to conflict with another, but some blends might go well together, so should not technically be hindered in doing so by the underlying mechanisms IMO. Debian is about structuring choices implemented in upstream code, and blending is in a sense about reducing choices to a sensible minimum. Makes sense for me that a blend maintains _what_ should be tweaked, but _how_ it is tweaked is better maintained by the package maintainer than blend maintainers or dpkg maintainers IMHO. When a blend includes full config files or scripted config tweaks then the package _maintainers_ are kept out of the loop of _maintaining_ those config choices, and the config options are not offered individually by Debian, e.g. for tools like piuparts to regression test in automated ways. I highly recommend to instead help make it easier for package maintainers to implement and _maintain_ config handling. I believe that if it was easier to implement and maintain debconf interfaces to config files, we would have less of a problem convincing them to offer config options for the tweaks we need for various blends. Specifically I believe that work to integrate debconf with Config::Model could help improve the situation. More on Config::Model here: http://wiki.debian.org/PackageConfigUpgrade > >> * 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 blended > > > >Above 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 mean tweaking mechanisms like config.d and dpkg-divert listed above. > >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. Correct. dpkg-divert is a dpkg mechanism so most likely needs development to happen in close collaboration with maintainers of dpkg. > 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 > package > > Both 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. I am pretty sure that anyone interested in blending would be excited if you invent/refine needed mechanisms for above two needs. ...if done Policy compliant - which does *not* mean weaken Policy but (understand reasons for and) obey Policy. I am less sure that anyone else will volunteer to do the work for you, if that's what you are asking. Personally I would not, because I cannot imagine such work bear fruit - i.e. become Debian Policy compliant. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature