Re: Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends
On Thu, Jan 26, 2012 at 04:27:40PM +0100, Jonas Smedegaard wrote:
> 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.
I just work down my backlog after traveling to Southport where we have
the second Debian Med sprint and followed your interesting discussion.
> > 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.
My opinion about having two (or more) Blends cooexisting on one machine
we need to differentiate between practical application and theoretical
implementation. I doubt that there is any *existing* machine which has
a need to have a real need to install two or more Blends and its
configuration files. This doubt is based on the fact that currently
only Debian Edu provides specific configuration at all (which probably
will change in the future). However, I would really love to see the
chance to enable the peaceful coexistence if possible at all so in other
words I think we should care for an implementation which enables the
theoretical chance to install more than one Blend on one machine.
> 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.
BTW, it might perfectly be the case that two Blends need the very same
change in the config and can not coexist just because we found a
mechanism which excludes two Blends on one machine. This would be
an unnecessary restriction.
> 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.
ACK
> 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.
ACK
> 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
I also would like to add the following: Mike's suggestion needs some
dpkg/apt/whatever coding first. It does not help to make good
suggestions if you will not come up with patches which you tested for
some time and than make the maintainers of this core functionality
accepting these patches. This is not an easy job and according to my
experience this takes ages. I'm comparing with how long it took to make
apt aware about description translations - and translations is a feature
about 50% of all Debian users might really *want*. Unfortunately we
need to realise that Blends is - like it or not - a quite unknown topic
in the Debian universe even if I try my best to talk about it at any
DebConf and other events. I like to quote Peter Eisentraut: "You are
talking about something which does not exist." Well, it is not that
drastical, but changing the Debian infrastructure on behalf of the needs
of Blends is at current state not realistic.
However, if we are talking about #311188 I think what we could try to
approach is making config issues of Blends RC critical and thus making
the bugs we filed against those packages RC critical which in turn would
enable us NMUing packages of maintainers which are not willing to help
us otherwise. I know that's also not very nice but would solve the
problem we are facing and is way more realistic to be solved until June
(suggested freeze time).
> 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.
Perfectly correct. You just will not manage to convince somebody else
to do the work for you. That's why I would suggest to find a way were
you can do the work yourself more easy (just do an NMU).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: