Hi Mike, On 12-01-26 at 11:13am, Mike Gabriel wrote: > To address #311188 the latest approach that has been discussed is > enrolling the maintainers of all affected packages (and that can be > many) to add blend-customized debconf values to their packages so that > a clean preseeding of the package is possible. Correct. Thanks for summarizing. [debathena comment snipped] > 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. > 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? 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. > * 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. 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. > * 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. Regards, - 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