[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