[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft proposal for handling configuration file manipulations in Debian blends

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.


 - 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

Reply to: