[debhelper-devel] debhelper updates

[Igor Kozhukhov]

Hi Nails,

thanks a lot for your updates on debhelper tree related to DilOS :)
apriciate it.

best regards,
-Igor

> On Apr 17, 2017, at 6:19 PM, Niels Thykier <niels at thykier.net> wrote:
> 
> 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
> 
> 
>