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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
