[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#423462: Bug#425700: sendmail_8.14.1-4(ia64/unstable): FBTFS: >= has no left operand



merge 425595 423462
thanks

On Wed, May 23, 2007 at 08:03:47AM -0700, Richard A Nelson wrote:
> 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.

Well, waldi disagrees and he usually has no problem breaking userspace use
of kernel headers when it's the right thing to do ;), so I think this change
in linux-libc-dev is going to be reverted.

> 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 :(

Right.

> I have a few possible fixes:

> Can we get linux-libc-dev to *NOT* provide linux-kernel-headers ?

I don't see any reason that it would hurt for l-l-d to drop the provides:,
but that won't help you anyway because l-k-h is deprecated and will be going
away as soon as l-l-d is fully on its feet.

> 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?).

Yep.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: