[debhelper-devel] debhelper updates

Niels Thykier niels at thykier.net
Mon Apr 17 15:19:00 UTC 2017

Igor Kozhukhov:
>> [...]
>> I am happy to consider some method for derivatives to change debhelper's
>> defaults but I don't have a design for that yet.  One of the things we
>> need is that debhelper does the right thing by default for Debian and
>> derivatives without the packager have to deal with it.
>> I know of other derivatives that would be greatly helped by this.
>> Unfortunately, I have not been able to prioritize that in the spare time
>> I use for debhelper.
> Well, I’d like propose to use vendor name - dpkg-vendor --derives-from DilOS
> if you have specific changes related to Linux - you can use: vendor != DilOS :)

I am afraid that cluttering the code with "if $vendor == THIS" and "if
$vendor != THAT" will not scale very well.  It will make debhelper
maintenance unbearable in the long run, plus I would be unable to
outsource the maintenance to the vendors themselves, whom are the best
candidates for keeping them up to date.

I have been considering a different idea where you as a vendor would be
able to supply debhelper with different defaults by installing a single
file with a given name.  Though it is on the idea basis for now, so I do
not have a concrete implementation/detail yet.

I will reply when I have something more concrete.  That said, I cannot
promise that the vendoring will be able to accommodate all of your
changes.  Also, please keep in mind that this work can easily be a year
or more away from being ready for consumption.

> [...]
> i have registered vendor=DilOS on my env and  i have plans contribute some updates DilOS specific to debhelper/dpkg/apt tools - how can i do it?
> i have updates for: dh_strip, dh_perms, dh_install, for conffiles, etc
> -Igor

I have checked[1], which I assume is your changes.  A quick run through

 * Makefile
   - With a few minor tweaks, I could take most of that and you would
     be reduced to just overriding 2-3 variables (e.g. PERL, POD2MAN,
     etc.) in the top.

 * autoscripts/*
   - I cannot accept those as they are.  Though it seems reasonable that
     a vendor system should enable you to replace autoscripts.
   - Also, I notice the changes remind me of the DPKG_ROOT proposal.
     Not that I am entirely sure DPKG_ROOT have the same scope as these

 * debian/control:
   - Sorry, I don't know a good way to integrate that.

 * dh:
   - Also no, but I think it would be reasonable to let a vendor system
     enable this kind of change.

 * dh_fixperms:
   - I don't mind carrying the code for @mode_0644_patterns, but it will
     be empty for Debian.  If the vendor system choose how to populate
     these lists (plus the one with "var/svc/method"), then you would
     get rid of the entire diff.

 * dh_installdeb:
   - I don't understand that change.  Is it because /etc/ is the wrong
     dir for conffiles in DilOS?

 * dh_makeshlibs:
   - Why do you need to disable the ldconfig trigger?  If you don't want
     anything to happen, it should be trivial to just remove the trigger
     from libc-bin.

 * dh_strip:
   - That is vastly different from what we are doing right now.  I think
     I will defer that one.
   - This might be "easier" to do as excluding dh_strip and then
     implementing a separate strip helper for that case.  Not a very
     satisfying answer though... :-/

 * run:
   - Why does this script require /bin/bash for DilOS?

So I reduce your diff for the files "Makefile" and "dh_fixperms" now.
With a proper vendor system in place, we might be able to do more.



More information about the debhelper-devel mailing list