[debhelper-devel] debhelper updates

[Igor Kozhukhov]

> 
> Igor Kozhukhov:
>> Hello,
>> 
> 
> Hi Igor,
> 
> Thanks for your work and interest in debhelper.
> 
>> i have DilOS - http://www.dilos.org <http://www.dilos.org/>
>> it is illumos based platform where i have ported APT/DPKG
>> 
>> i do some updates on my platform bsed on debian mainstream - right now from stretch
>> 
>> i do mirror of some components to bitbucket and i see updates.
>> 
>> i see update to debhelper:
>> https://bitbucket.org/dilos/debhelper/commits/ea1b656f937c60f0d06d5272c149cb873b7d8ac6 <https://bitbucket.org/dilos/debhelper/commits/ea1b656f937c60f0d06d5272c149cb873b7d8ac6>
>> 
>> where you point to use —runstatedir=/run - but it mistake on DilOS - where i have SMF as service manager - not systemd.
>> 
> 
> Please note that /run is:
> * supported by the Debian policy[1]
> * blessed by FHS 3.0[2]
> 
> In both cases, /run replaces /var/run.  A quick fix would be to make
> /run a symlink to /var/run (or vice versa, which is what Debian did).
> 
> [1]  https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
> 
> [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
> 

thanks for your replies :)
i have /var/run as tmpfs on DilOS and no need to use link to /run - it is platform specific
also, /tmp = tmpfs too.
i’m using /var/tmp if i need to work with larges files and for some others case - platform specific similar to solaris.

> 
>> i have no provided my updates to APT/DPKG and others debian tools because work still in progress on updates and i’m working on updates by my free time only.
>> 
>> if it is possible - could you please do not lock tools to systemd specific and some specific changes mark if systemd defined?
>> it can help to me with my futures ports/updates - do to hack tools for my build env and use upsmtreamed tools.
>> 
>> bets regards,
>> -Igor
>> 
>> [...]
> 
> 
> 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’ll try to check it and provide update if needed.

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

> Thanks,
> ~Niels
> 
> 

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