Re: dpkg updates for DilOS
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
Reply to: