<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">I am happy to consider some method for derivatives to change debhelper's<br class="">defaults but I don't have a design for that yet.  One of the things we<br class="">need is that debhelper does the right thing by default for Debian and<br class="">derivatives without the packager have to deal with it.<br class=""><br class="">I know of other derivatives that would be greatly helped by this.<br class="">Unfortunately, I have not been able to prioritize that in the spare time<br class="">I use for debhelper.<br class=""></blockquote><br class="">Well, I’d like propose to use vendor name - dpkg-vendor --derives-from DilOS<br class=""><br class="">if you have specific changes related to Linux - you can use: vendor != DilOS :)<br class=""></blockquote><br class="">I am afraid that cluttering the code with "if $vendor == THIS" and "if<br class="">$vendor != THAT" will not scale very well.  It will make debhelper<br class="">maintenance unbearable in the long run, plus I would be unable to<br class="">outsource the maintenance to the vendors themselves, whom are the best<br class="">candidates for keeping them up to date.<br class=""><br class="">I have been considering a different idea where you as a vendor would be<br class="">able to supply debhelper with different defaults by installing a single<br class="">file with a given name.  Though it is on the idea basis for now, so I do<br class="">not have a concrete implementation/detail yet.<br class=""><br class="">I will reply when I have something more concrete.  That said, I cannot<br class="">promise that the vendoring will be able to accommodate all of your<br class="">changes.  Also, please keep in mind that this work can easily be a year<br class="">or more away from being ready for consumption.<br class=""><br class=""><blockquote type="cite" class="">[...]<br class=""><br class="">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?<br class="">i have updates for: dh_strip, dh_perms, dh_install, for conffiles, etc<br class=""><br class="">-Igor<br class=""><br class=""></blockquote></div></div></blockquote><div><br class=""></div><div>my changes on my tree on branch 'dilos'</div><div><a href="https://bitbucket.org/dilos/dilos-debhelper/commits/all" class="">https://bitbucket.org/dilos/dilos-debhelper/commits/all</a></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">I have checked[1], which I assume is your changes.  A quick run through<br class="">them:<br class=""><br class=""> * Makefile<br class="">   - With a few minor tweaks, I could take most of that and you would<br class="">     be reduced to just overriding 2-3 variables (e.g. PERL, POD2MAN,<br class="">     etc.) in the top.<br class=""></div></div></blockquote><div><br class=""></div><div>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</div><div>it is idea for others tools to.</div><div><br class=""></div><div><pre class="source" style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 0px 72px; font-family: Consolas, Menlo, 'Liberation Mono', Courier, monospace; line-height: 18px; color: rgb(51, 51, 51); height: 18px; background-color: rgb(221, 255, 221);">POD2MAN=<ins style="display: inline-block; margin-top: -1px; text-decoration: none; background-color: rgb(151, 242, 149);" class="">$(PERL) /usr/bin/</ins>pod2man --utf8 -c Debhelper -r "$(VERSION)"</pre><div class=""><br class=""></div><div class="">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.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""> * autoscripts/*<br class="">   - I cannot accept those as they are.  Though it seems reasonable that<br class="">     a vendor system should enable you to replace autoscripts.<br class="">   - Also, I notice the changes remind me of the DPKG_ROOT proposal.<br class="">     Not that I am entirely sure DPKG_ROOT have the same scope as these<br class="">     changes.<br class=""></div></div></blockquote><div><br class=""></div><div>well. illumos tools, like installation of modules support BASEDIR as environment variable - and more others tools.</div><div>i have updated dpkg/apt setup this environment variable by: dpkg -R <BASEDIR> -i <deb package>, apt-get -R <BASEDIR> install package</div><div><br class=""></div><div>i need it for new bootstrap and for installation of packages to another root - for example - to zones. (zones = solaris virtualization similar to chroot)</div><div>i cna’t use chroot - it has more restrictions for setup/install packages to another root</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""> * debian/control:<br class="">   - Sorry, I don't know a good way to integrate that.<br class=""></div></div></blockquote><div><br class=""></div><div>ctftools [solaris-any] - can be as dependencies for DilOS.</div><div>right now i have target host:</div><div>solaris-i386 = Intel platform 64bit</div><div>solaris-sparc = SPARC platform 64bit</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * dh:<br class="">   - Also no, but I think it would be reasonable to let a vendor system<br class="">     enable this kind of change.<br class=""></div></div></blockquote><div><br class=""></div><div>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?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * dh_fixperms:<br class="">   - I don't mind carrying the code for @mode_0644_patterns, but it will<br class="">     be empty for Debian.  If the vendor system choose how to populate<br class="">     these lists (plus the one with "var/svc/method"), then you would<br class="">     get rid of the entire diff.<br class=""></div></div></blockquote><div><br class=""></div><div>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</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * dh_installdeb:<br class="">   - I don't understand that change.  Is it because /etc/ is the wrong<br class="">     dir for conffiles in DilOS?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * dh_makeshlibs:<br class="">   - Why do you need to disable the ldconfig trigger?  If you don't want<br class="">     anything to happen, it should be trivial to just remove the trigger<br class="">     from libc-bin.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""> * dh_strip:<br class="">   - That is vastly different from what we are doing right now.  I think<br class="">     I will defer that one.<br class="">   - This might be "easier" to do as excluding dh_strip and then<br class="">     implementing a separate strip helper for that case.  Not a very<br class="">     satisfying answer though... :-/<br class=""></div></div></blockquote><div><br class=""></div><div>we have another tools - like ctftools - and strip operations - i don’t know how to split it based on platform</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""> * run:<br class="">   - Why does this script require /bin/bash for DilOS?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div>specify /bin/bash can reduce issues with default shell.</div><div>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</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">So I reduce your diff for the files "Makefile" and "dh_fixperms" now.<br class="">With a proper vendor system in place, we might be able to do more.<br class=""></div></div></blockquote><div><br class=""></div><div>thanks for your review and questions/comments ;)</div><div><br class=""></div><div>please let me know if we can colaborate on updates.</div><div><br class=""></div><div>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></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Thanks,<br class="">~Niels<br class=""><br class="">[1]<br class=""><a href="https://bitbucket.org/dilos/dilos-debhelper/commits/55f846b5d8f1fdd8ed4f00d271cbc949c160abbe" class="">https://bitbucket.org/dilos/dilos-debhelper/commits/55f846b5d8f1fdd8ed4f00d271cbc949c160abbe</a><br class=""><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>