Hi! On Sun, 2017-04-23 at 15:31:22 +0300, Igor Kozhukhov wrote: > i have platfrom DilOS (http://www.dilow.org <http://www.dilow.org/>) > it is illumos based plarform, but it is not illumos as is. > illumos - it is fork from OpenSolaris.
I know, :) I've got it tracked as one of dpkg downstreams, which I try to take a look from time to time to see what needs to be fixed/improved in upstream. <https://wiki.debian.org/Teams/Dpkg/Downstream> I had pending reaching out, so thanks for doing yourself that instead. :) > I have ported and updated DPKG + APT for works better with my platforms. > > my changes what i’m using on DilOS you can find at: > https://bitbucket.org/dilos/dilos-dpkg/commits/217a5a7e18af8b28ee21b9d1c0e319fc0e256804 > > <https://bitbucket.org/dilos/dilos-dpkg/commits/217a5a7e18af8b28ee21b9d1c0e319fc0e256804> I went trough those changes some time ago, and several seem incorrect. I've also been looking for access to a Solaris (or deirved) system [P], and was considering DilOS for that, but having to keep yet another VM image and administer it takes time, so I've postponed that. If you have readily available access you could give away to such a system that would help when doing portability work or for build tests and similar. [P] <https://wiki.debian.org/Teams/Dpkg/Porting> > let me explain some changes. > > right now we have no definition related to 'illumos' and still using > 'solaris' with 'SunOS' it is why you can see from changes with '__sun' > and 'OS_Solaris' > > question is - will it better if i’ll tyr to use : > #if defined(DILOS) - and will define it by vendor definition to > CPPFLAGS += -DDILOS ? > > DilOS != illumos - i have more updates on my fork. because illumos > community have own visions to tools and dislike ideas to have GNU > tools in promary place - like: grep, sed, find, etc - and prefer to > use illumos tools and hack/update userland apps for it. solaris and __sun or OS_Solaris in these contexts mean just the kernel, so as long as you are not going to diverge and fork the kernel itself, then using DilOS here would be wrong. Userland should not change non-kernel related behavior based on those macros. The tools in userland could be BSD/GNU/Solaris or whatever, which is something that cannot be told from these macros. For example start-stop-daemon is kernel specific, but it should not care about userland in general. > we are using dpkg -R <another root> <flags> *.deb & > apt-get -R <another root> <flags> <list of packages> - for better > compatibility with IPS pkg tools and better works with zones (solaris > zones virtualization). This change is wrong, you have taken the -R option which was already in use and given it a different meaning, this will break things that use that option. Also I feel this conflicts with the DPKG_ROOT <https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap>. And the zones support has come up before; and my opinion, which has gone unchallenged, as no one ever seemed to argue I was wrong, is that the zones support is broken by design, see: <https://lists.debian.org/debian-dpkg/2011/11/msg00040.html> > I do only 64bit builds/ports, but have some 32bits components for > trasition period > > we are using solaris-i386 for 64bit on Intel and solaris-sparc for > 64bit on SPARC. This is the other change that seemed wrong. Please see <https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F>, which contains information about the architecture names, and the rationale for those. I'll cover some of the problems here anyway: > dpkg-architecture on Intel is: > > $ dpkg-architecture > DEB_BUILD_ARCH=solaris-i386 Is DilOS binary compatible with stock Solaris, Illumos, etc? Does it use the same libc? Otherwise it will need its own arch name. The cpu part in the arch name should reall be amd64 here… > DEB_BUILD_ARCH_ABI=base > DEB_BUILD_ARCH_BITS=64 > DEB_BUILD_ARCH_CPU=amd64 > DEB_BUILD_ARCH_ENDIAN=little > DEB_BUILD_ARCH_LIBC=sysv > DEB_BUILD_ARCH_OS=solaris > DEB_BUILD_GNU_CPU=x86_64 > DEB_BUILD_GNU_SYSTEM=pc-solaris2.11 > DEB_BUILD_GNU_TYPE=x86_64-pc-solaris2.11 More so when the GNU type contains x86_64. > DEB_BUILD_MULTIARCH=amd64 This is wrong, it needs to be the normalized DEB_BUILD_GNU_TYPE, which means pretty much the same value except for i386, which instead of having something like i686-* it would have i386-*. > on SPARC: > $ dpkg-architecture > DEB_BUILD_ARCH=solaris-sparc > DEB_BUILD_ARCH_ABI=base > DEB_BUILD_ARCH_BITS=64 > DEB_BUILD_ARCH_CPU=sparc64 > DEB_BUILD_ARCH_ENDIAN=big > DEB_BUILD_ARCH_LIBC=sysv > DEB_BUILD_ARCH_OS=solaris > DEB_BUILD_GNU_CPU=sparcv9 > DEB_BUILD_GNU_SYSTEM=sun-solaris2.11 > DEB_BUILD_GNU_TYPE=sparcv9-sun-solaris2.11 > DEB_BUILD_MULTIARCH=sparcv9 The same comments as the amd64 but with sparc vs sparc64. > as you can see - for MULTIARCH we are using 'amd64' & 'sparcv9' - > because we have for 64bits isaexec definitions lile: Each dpkg architecture needs to be a disctint ABI, so 32 and 64-bit binaries need their own arches. What really defines the architecture in dpkg, is: 1) «dpkg --print-architecture» for the build/native architecture. 2) «gcc -dumpmachine» or equivalent compiler option that states what is it building for; for the host architecture. > where /lib/64 is link to plarform specific: 'amd64' on intel and 'sparcv9' > on sparc In dpkg/Debian-land we call this a multilib layout, and we are trying to phase those out. We have switched to the multiarch layout and tooling, which I'd recommend you follow too, as it would allow you to have all of DilOS i386, amd64, sparc and sparc64 shared libraries on the same system, making cross-compilation way easier. Although I realize that if this is hardcoded in the Solaris userland then that might be more tricky/work. But IMO the multilib layout is a pain, because it causes many problems, needs much special casing, and is not uniform and general, and it should really die. That's something I'd like to see in Debian, so that might start affecting downstreams at some point or another. > it is solaris specific where we can’t indetify correct plarform by 'uname' > $ uname -a > SunOS bld01 5.11 1.3.7.182 sun4v sparc SUNW,SPARC-Enterprise-T5220 > > $ uname -a > SunOS z172 5.11 1.3.7.182 i86pc i386 i86pc > and we have to use 'isainfo' tools for 32/64 bits identifucation. You should not need to use uname in the dpkg context. You might need to patch config.guess if it's not detecting the system properly though, but that's independent of this. > first question: what Debian specific platfrom will be better to use > instead of solaris-i386 & solaris-sparc ? Please see my other comments and the references I've given, and once you have checked those we can probably go over this again with any doubts you have? > next question: about BASEDIR definition. Please see my other comments too. :) > Pleae let me know your questions/updates - how we can colaborate and > how to update DilOS better for it :) I'm always happy to make dpkg more portable, and to merge anything that would help it build and run on other systems, and to try to reduce the delta carried by downstreams. Some additional comments about your delta: - Why is -ltinfo necessary, that should have been picked up by configure automatically, if not I'd like to see build logs. - Does rpath not work on Solaris? - If the test suite fails I'd like to see the output too. OTOH there have been many portability fixes in recent 1.18.x releases so you might want to upgrade to see if this is still the case. - I guess the sh → bash changes is due to the ksh stuff you were mentioning on the debhelper list? - About the ldconfig stuff, I should protect that with __GLIBC__. I've not added crle stuff there yet because the Dpkg::Shlibs in general have no support for anything not objdump based. :( I think the Illumos port has done some work on that front though. - There's been several patches to add --root directory support to update-alternatives, but they were not entirely correct. I've made several changes in recent releases to make this easier in the future. And I'm planning to make most of the dpkg tools alt-root capable during the 1.19.x cycle. - I'm interested in making start-stop-daemon build and work out of the box on Solaris, I've just lacked access to such a system. Thanks, Guillem
