Bug#423462: Bug#425700: sendmail_8.14.1-4(ia64/unstable): FBTFS: >= has no left operand
On Wed, 23 May 2007, Martin Michlmayr wrote:
* lamont@debian.org <lamont@debian.org> [2007-05-23 06:48]:
from editmap.c:41:
../../include/sm/conf.h:1478:27: error: operator '>=' has no left operand
../../include/sm/conf.h:1527:27: error: operator '>=' has no left operand
This is because of headers, see #425595
Yes, a user reported this, so I added (and it is in -4)
Build-Depends: make (>> 3.79.1-14), m4, patch, debhelper (>= 4.1.68),
linux-kernel-headers ....
Ah....
Package: linux-libc-dev
Source: linux-2.6
Version: 2.6.21-2
Replaces: linux-kernel-headers, linux-libc-headers
Provides: linux-kernel-headers
Conflicts: linux-kernel-headers, linux-libc-headers
So, the mess gets worse - postfix, sendmail, gcj, and a plethor of other
packages :(
In general, I agree with Steve's comment about user code and the linux/*
header space.
However, I don't see a workaround for sendmail/postfix - who are looking
not at the running kernel, but for a working feature set indication... And
there is not current API that I am aware of that provides this, other
than the headers :( Yes, I understand that the linux/* header set may
not match the extant kernel :(
Worse, some of the items tested for (does flock() work) aren't exactly
the kinds of things you *would* have in capabilities string - even if we
actually had one.
A few examples from sendmail, with annotations:
# if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,19))
# define SM_CONF_SHM 1 /* Shared memory broke before this */
# if LINUX_VERSION_CODE < 66399
# define HASFLOCK 0 /* flock(2) is broken after 0.99.13 */
# if (LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0))
# define HASFLOCK 1 /* flock(2) fixed after 1.3.95 */
# else /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)) */
# define HASFLOCK 0 /* flock(2) is broken (again) after 2.4.0 */
# if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,0,0))
# ifndef HASURANDOMDEV
# define HASURANDOMDEV 1 /* 2.0 (at least) has linux/drivers/char/random.c */
The list goes on, but the idea is that, however unfortunate, sometimes
a system application needs to know what it can expect from the kernel,
and the library:
# else /* (GLIBC_VERSION >= 0x201) */
# include <linux/in6.h> /* IPv6 support */
# if (GLIBC_VERSION >= 0x201 && !defined(NEEDSGETIPNODE))
/* Have APIs in <netdb.h>, but no support in glibc */
# define NEEDSGETIPNODE 1
I have a few possible fixes:
Can we get linux-libc-dev to *NOT* provide linux-kernel-headers ?
Although, I think the *BEST* idea would be for linux-libc-dev to
actually define LINUX_VERSION_CODE to the lowest level of kernel that is
supported (now, what - 2.6.18?).
For sendmail, postfix, and I'm sure some of the others, the only
remaining alternative (and I've not yet tried it) is for the maintainer
to add -DLINUX_VERSION_CODE=<2.6.18 in decimal format>
This alternative is going to bite us in the future, if we again have an
issue like flock() breaking on certain kernels.
--
Rick Nelson
<Manoj> shaleh: I am not, despite your implication, God
Reply to: