[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
them:
* 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
changes.
* 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.
Thanks,
~Niels
[1]
https://bitbucket.org/dilos/dilos-debhelper/commits/55f846b5d8f1fdd8ed4f00d271cbc949c160abbe
More information about the debhelper-devel
mailing list