At Fri, 21 Jan 2005 19:51:22 +0100,
Martin Kittel wrote:
> Recently upstream has converted the database kernel from
> linuxthread-style threading to NPTL. While -at least for i386-
> linuxthreads is still supported in MaxDB at this time, it will go away
> in one of the next releases.
> As far as I know there is no NPTL support in 2.4 debian kernels (as for
> example in some RedHat 2.4 kernels). Is that correct?
> In that case I will have to add a dependency on kernel-image-2.6 or does
> anyone know of a better way to express a dependency on NPTL style threading?
I don't read these threads entirely, so some opinions may be
duplicated in other messages.
(1) The correct way to detect NPTL availability is: check the result
value of "getconf GNU_LIBPTHREAD_VERSION":
[EMAIL PROTECTED]:~> uname -a
Linux celesta 2.6.8-1-686-smp #1 SMP Mon Sep 13 23:02:39 EDT 2004 i686
GNU/Linux
[EMAIL PROTECTED]:~> getconf GNU_LIBPTHREAD_VERSION
NPTL 0.60
[EMAIL PROTECTED]:~> env LD_ASSUME_KERNEL=2.4.1 getconf
GNU_LIBPTHREAD_VERSION
linuxthreads-0.10
You can check it in your wrapper script. If your wrapper script
detects NPTL unavailability, you can put warning message.
One problem is old libc6 does not include /usr/bin/getconf (until
2.3.2.ds1-13, it was included in libc6-dev). So your package
should depend on at least 2.3.2.ds1-14 if this method is used
(because the current libc6 shlib deps is 2.3.2.ds1-4).
(2) Most architectures do not support NPTL currently. Debian
glibc-2.3.2.ds1-20 supports NPTL on i386, amd64, ia64 and s390.
So your package is available on only four architectures.
(We have plan to add NPTL support for alpha, ppc and ppc64 in the
next glibc update. However, currently NPTL is not supported even
in upstream cvs on arm (EABI update), mips (tls register
discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is
everytime big problem in computer history). It's sure that hurd
and *bsd are out of scope with NPTL.)
(3) NPTL is POSIX thread library - I wonder why your package has to
depend on NPTL. It's sure there're a lot of incapability to
handle the whole POSIX threading requirement with linuxthreads -
but it has basic features to use pthread. Depending on the
specific implementation is not good idea, IMHO. Martin, I would
like to know why such requirement is needed.
(4) In general, depending on the specific kernel package causes
various problems as other mails are already mentioned. MaxDB
should not use check kernel version because it's related with
threading system, not kernel version.
However some packages really needs kernel version checking - one
example is glibc package. It detects old kernel version using
"uname" in libc6.preinst. If old kernel version is detected,
preinst warns with messages and just exits.
(Note that I'll add "uname detection" not only in preinst but also
in /etc/init.d in future, though. I notice that we can possibly
put a generic kernel version detection mechanism for this kind of
purpose.)
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
