[config-package-dev] transform

[Patrick Schleizer]

Benjamin Kaduk:>> At the moment as I understand it:
>> - config file to be transformed should be available at package build
>> time (provided by original package)
>> - transformation script is applied at package build time
>> - when upstream releases a new config file, these changes won't be
>> included in the transformed config as long as the config package does
>> not get upgraded
>> - disadvantage: to be transformed package is a build dependency
>> - disadvantage: config package must be updated every time upstream
>> releases a new config that should be applied as well
>>
>> Wouldn't it be better to just apply the patch every time upstream
>> releases a new config file?
>
> It has been some time since I thought about this question, but I believe
> the issue is what happens in the case that the transformation script
> fails: if the transformation is applied at package build time, the
> package build fails, and the old version of the configuration package
> remains in the archive, so clients never see a broken package.  If the
> transformation is applied as a trigger on updates of the package being
> configured, then a failure of the transformation script could leave the
> client system in a broken state.

Good points.

If transformation fails, it would be up to the transformation script if
it prefers to fail closed and exit 1 or to ignore the error, fail open
and exit 0. In case of only appending stuff it should work well. I guess
both approaches are worthwhile. What do you think?

What would be a good name for this feature? .patch instead of .transform?

>> In my case, I only wish to append a few lines below in the config of
>> what upstream does above.
>
> This is the sort of thing that motivates the creation of conf.d/
> directories for placing configuration file snippets.

I am a big fan of this.

> It might be worth
> asking upstream to consider adding such support; then the configuration
> package can just install a snippet to that directory.

Upstream might accept a patch. And I am likely able to implement the .d
thing. In this case it's an /etc/default/configfile. I haven't seen any
/etc/default/name.d folders yet for any package. Does this exist?