[debhelper-devel] debhelper updates

Igor Kozhukhov igor at dilos.org
Mon Apr 17 15:43:49 UTC 2017


>>> 
>>> 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
>> 

my changes on my tree on branch 'dilos'
https://bitbucket.org/dilos/dilos-debhelper/commits/all <https://bitbucket.org/dilos/dilos-debhelper/commits/all>


> 
> 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.

we can provide PERL env var to another perl - if we have installed it for transition to build env and need new debhellper package based on new PERL
it is idea for others tools to.

POD2MAN=$(PERL) /usr/bin/pod2man --utf8 -c Debhelper -r "$(VERSION)"

this one mean - to use NEW PERL from env var, instead from build host - and use pod2man with new PERL with dependencies instead of from build host.

> 
> * 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.

well. illumos tools, like installation of modules support BASEDIR as environment variable - and more others tools.
i have updated dpkg/apt setup this environment variable by: dpkg -R <BASEDIR> -i <deb package>, apt-get -R <BASEDIR> install package

i need it for new bootstrap and for installation of packages to another root - for example - to zones. (zones = solaris virtualization similar to chroot)
i cna’t use chroot - it has more restrictions for setup/install packages to another root

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

ctftools [solaris-any] - can be as dependencies for DilOS.
right now i have target host:
solaris-i386 = Intel platform 64bit
solaris-sparc = SPARC platform 64bit

i’ll try to talk with dpkg guys about target platfrom name a little later when i can show how it can work with final platform - this work is in progress.

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

i don’t know how to ignore some dh_ scripts in dh based on platform specific - it is why i just removed one dh_strip_nondeterminism here - do you have ideas how to do it better?

> * 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.

we have different way with permissions - for example: i need chmod 0755 for shared libs on DilOS - it was opensolaris basaed specific and maybe later it can be changes, but not right now. also, i need to controll adiitional directories for SMG services

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

idea with conffiles is: if we provide conffiles in component - no need generate it - just use it. for example: in DilOS i can override more files in /etc - i no need controll it with update/upgrade, but i want to be able to add some files from component what i’d like to control.

> * 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.

on DilOS - we no need to run ldconfig - we are using crle - and no need run it every time with new hanged libs installed - solaris specific with run time linker.

> 
> * 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... :-/

we have another tools - like ctftools - and strip operations - i don’t know how to split it based on platform

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

well - we can use /bin/ksh as default shell - link ksh -> /bin/sh - and it is issue with BASH specific like 'local' special words and others.
specify /bin/bash can reduce issues with default shell.
more illumos distributions are have KSH93 as default shell, but with DilOS i try to move to use DASH as primary shell, but this work still in progress - not easy move from KSH -> DASH

> 
> 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 for your review and questions/comments ;)

please let me know if we can colaborate on updates.

right now i’m more interested in opportunity to ignore files for dh_install by list from external file, instead of per file in -X<item>

> Thanks,
> ~Niels
> 
> [1]
> https://bitbucket.org/dilos/dilos-debhelper/commits/55f846b5d8f1fdd8ed4f00d271cbc949c160abbe
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20170417/38a4cbc8/attachment.html>


More information about the debhelper-devel mailing list