Sam == Sam Hartman [EMAIL PROTECTED] writes:
Sam We are making active decisions related to this problem. Ben is
Sam actively removing headers not used by libc6-dev;
For what it is worth, I do not agree with this process. I
still think that libc-dev should come with a snapshot of the
Sam == Sam Hartman [EMAIL PROTECTED] writes:
Manoj We already have a process for packages that actually do
Manoj need kernel headers, and are thus dependent on particular
Manoj kernel versions.
Sam We do? please explain what it is.
Manoj We call these packages kernel modules; and we have
Herbert == Herbert Xu [EMAIL PROTECTED] writes:
Herbert Sam Hartman [EMAIL PROTECTED] wrote:
This brings up an interesting point. While we should work with
upstream maintainers to fix these problems, we should also try
to avoid making these programs harder to build on Debian
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Sam == Sam Hartman [EMAIL PROTECTED] writes:
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes:
Aaron So you're saying it's better to hardcode syscall numbers
Aaron and stuff
On Tue, May 08, 2001 at 09:20:27AM -0400, Sam Hartman wrote:
We are making active decisions related to this problem. Ben is
actively removing headers not used by libc6-dev; there may be other
I didn't know that. That's something that I don't agree with.
--
Debian GNU/Linux 2.2 is out! (
On Mon, May 07, 2001 at 01:50:45AM +0200, Adrian Bunk wrote:
(I tried my best but I can't garuantee this is 100% complete...)
I won't look at all of them as this is really the upstream maintainer's job.
fdisk:
linux/unistd.h
This one is always OK for obvious reasons.
linux/hdreg.h
A
Herbert == Herbert Xu [EMAIL PROTECTED] writes:
Herbert I won't look at all of them as this is really the
Herbert upstream maintainer's job.
This brings up an interesting point. While we should work with
upstream maintainers to fix these problems, we should also try to
avoid making
Sam == Sam Hartman [EMAIL PROTECTED] writes:
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes:
Aaron So you're saying it's better to hardcode syscall numbers
Aaron and stuff than using the kernel headers? Sre...
Manoj We already have a
In article [EMAIL PROTECTED],
Ben Collins [EMAIL PROTECTED] wrote:
People should not be using them, but if they do, they should use a
kernel-headers package, and not rely on the headers in libc6-dev which
are different on all archs, and change almost every new glibc build. You
are never
Manoj Srivastava [EMAIL PROTECTED] wrote:
Out of curiosity, apart from linux/autoconf.h; what is the
difference between the header packages on i386?
include/config/* and include/linux/modules/*.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~}
Sam Hartman [EMAIL PROTECTED] wrote:
This brings up an interesting point. While we should work with
upstream maintainers to fix these problems, we should also try to
avoid making these programs harder to build on Debian than other
distributions. If other distributions are still making
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
So you're saying it's better to hardcode syscall numbers and stuff
than using the kernel headers? Sre...
Also chiming in: Suppose my code reads a struct from a
On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote:
Also chiming in: Suppose my code reads a struct from a device file.
That struct is defined in a kernel header (not part of glibc). You're
saying I should duplicate that header in my source rather than
build-depend on
On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote:
On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote:
Also chiming in: Suppose my code reads a struct from a device file.
That struct is defined in a kernel header (not part of glibc). You're
saying I should duplicate
On Sat, May 05, 2001 at 03:06:11PM -0500, Manoj Srivastava wrote:
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben False. That is the very thing I want to alleviate (people using kernel
Ben headers from the libc6-dev package).
However, that is what 99% of the programs out there need to
Anthony Towns aj@azure.humbug.org.au wrote:
All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
which used to be in libc6-dev, but isn't any longer)
For a legacy application like ipmasqadm, the solution is to simply copy
ip_masq.h from a 2.2 kernel tree and be done with it.
--
On Sun, May 06, 2001 at 10:43:25AM +0200, Torsten Landschoff wrote:
On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote:
Yes, because otherwise your code probably won't compile.
... when the kernel interface changed. Now tell me what is better -
Nope, they won't compile at all
On Sun, 6 May 2001, Herbert Xu wrote:
...
the package not building with the changed kernel or not working after
being installed at x*1000 machines?
What is better is a sane local header that works with all kernels.
I maintain util-linux that is a user space package that needs many kernel
On Sun, May 06, 2001 at 12:28:32PM +0200, Adrian Bunk wrote:
I maintain util-linux that is a user space package that needs many kernel
headers (and the package in unstable compiles only with 2.4 kernel
headers). I do currently use the kernel haeaders libc6-dev ships. Would
it be the right
On Sun, 6 May 2001, Herbert Xu wrote:
I maintain util-linux that is a user space package that needs many kernel
headers (and the package in unstable compiles only with 2.4 kernel
headers). I do currently use the kernel haeaders libc6-dev ships. Would
it be the right solution to copy the
Anthony == Anthony Towns aj@azure.humbug.org.au writes:
Anthony All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
Anthony which used to be in libc6-dev, but isn't any longer)
% cp /path/to/old/kerhnel/source/include/linux/ipmasq.h ipmasq.h
manoj
--
The mosquito
Itai == Itai Zukerman [EMAIL PROTECTED] writes:
Itai Why not have the default KSRC be /usr/src/kernel-headers-X.X? I
Itai think that's what Ben suggested...
Are you aware that that is what we used to do, circa libc5
days? And that we have moved away from that, for all the reasons
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes:
Aaron So you're saying it's better to hardcode syscall numbers and stuff
Aaron than using the kernel headers? Sre...
We already have a process for packages that actually do need
kernel headers, and are thus dependent on particular
Adrian == Adrian Bunk [EMAIL PROTECTED] writes:
Adrian I maintain util-linux that is a user space package that needs
Adrian many kernel headers (and the package in unstable compiles
Adrian only with 2.4 kernel headers). I do currently use the kernel
Adrian haeaders libc6-dev ships. Would it
On Sun, May 06, 2001 at 03:45:39PM +0200, Adrian Bunk wrote:
What do you suggest in my specific case with util-linux?
Which specific program in util-linux and what specific headers?
You mean every upstream source should ship it's own kernel headers?
Yes, they should ship their own headers
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes:
Aaron So you're saying it's better to hardcode syscall numbers
Aaron and stuff than using the kernel headers? Sre...
Manoj We already have a process for packages that
Sam Hartman [EMAIL PROTECTED] wrote:
We do? please explain what it is. Herbert produces kernel headers
packages for all flavors of kernels he produces. I do not believe the
other arches do this.
You obviously weren't listening to me when I explained this in the bloat
thread. If you aren't
Herbert == Herbert Xu [EMAIL PROTECTED] writes:
Herbert Sam Hartman [EMAIL PROTECTED] wrote:
We do? please explain what it is. Herbert produces kernel
headers packages for all flavors of kernels he produces. I do
not believe the other arches do this.
Herbert You
On Mon, 7 May 2001, Herbert Xu wrote:
What do you suggest in my specific case with util-linux?
Which specific program in util-linux and what specific headers?
...
(I tried my best but I can't garuantee this is 100% complete...)
fdisk:
linux/unistd.h
linux/hdreg.h
linux/blkpg.h
linux/types.h
In short, how do you do them?
AFAICT, I could conceivably add either
Build-Depends: kernel-headers
or
Build-Depends: kernel-headers-2.2.19
If I did the former, there doesn't seem to be any way to reliably
get at the kernel headers. The only way I can see is to hardcode
-I/usr
Anthony Towns aj@azure.humbug.org.au wrote:
The latter'll obviously break as soon as 2.2.20 comes out and 2.2.19 gets
removed from the archive.
If you're building modules, then they'll have to be rebuilt when 2.2.20
comes out anyway. If this is a user-space program, then it better stop
using
In short, how do you do them?
What do you want to do with them?
There are a whole load of wacky special source dependencies (*LINUX24-HEADERS
and so on) which seem to be trying to solve variants of this problem. But
this mechanism doesn't seem to be all that robust either.
I think the whole
Philip Blundell [EMAIL PROTECTED] wrote:
I think the whole idea of putting the kernel version number in the name of
the
headers package is pretty bogus. It would probably be better to just have a
kernel-headers package which installed itself in /usr/src/kernel-headers;
then you could
Having version numbers in the kernel-headers package name is a consequence
of having them in the kernel-image package name. The point of having them
in the kernel-image package name should be pretty obvious...
Actually, I'm not even completely convinced that having them in the
kernel-image
On Sat, May 05, 2001 at 06:23:39PM +1000, Anthony Towns wrote:
In short, how do you do them?
AFAICT, I could conceivably add either
Build-Depends: kernel-headers
or
Build-Depends: kernel-headers-2.2.19
or
Build-Depends: kernel-headers-2.2
or
Build-Depends
On Sat, May 05, 2001 at 06:07:54AM -0400, Ben Collins wrote:
On Sat, May 05, 2001 at 06:23:39PM +1000, Anthony Towns wrote:
In short, how do you do them?
AFAICT, I could conceivably add either
Build-Depends: kernel-headers-2.2
or
Build-Depends: kernel-headers-2.4
You'll notice
On Sat, May 05, 2001 at 10:27:53AM +0100, Philip Blundell wrote:
Actually, I'm not even completely convinced that having them in the
kernel-image package name is particularly beneficial. But, even if we leave
that the way it is, I don't think it's impossible to arrange for
kernel-headers
Anthony Towns aj@azure.humbug.org.au wrote:
On Sat, May 05, 2001 at 06:07:54AM -0400, Ben Collins wrote:
AFAICT, I could conceivably add either
Build-Depends: kernel-headers-2.2
or
Build-Depends: kernel-headers-2.4
You'll notice that recent kernel-headers packages provide
.
Also, I think that packages should Build-Depends on kernel-headers-X.X.
IMO, There is no reason to build-dep on anything more specific, and also
no reason to build-dep on just kernel-headers (IOW, maintainers should
test which kernel headers can be used). This way they can always just
do:
CFLAGS
On Sat, May 05, 2001 at 11:09:20AM -0400, Ben Collins wrote:
The point here is to make packages start moving to Build-Dep'ing on
kernel-headers-* packages. The question is, how to allow them to do that
easily.
IMO, we can use alternatives. And it should be fairly easy
update-alternatives
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben False. That is the very thing I want to alleviate (people using kernel
Ben headers from the libc6-dev package).
However, that is what 99% of the programs out there need to
do, since they really are not dependent on the specifics of
(as in 2.2.19). This way each
newer version would be prefered over the former. The only problem I see
are the -preX releases. Someone would have to suggest how to handle that
case since the priority field wont accept letters.
Also, I think that packages should Build-Depends on kernel-headers-X.X
Now, how are we going to support: If there's a version of libc6 that's
known to use kernel headers incompatible with a particular
kernel-headers-*, then a package compiled against those kernel headers
should conflict with that libc6.
Eh? Why would this be useful?
p.
Je 05 May 2001 15:06:11 -0500,
Manoj Srivastava [EMAIL PROTECTED] scribis:
Try this: suggest the kernel-headers package, and set
CFLAGS += -I$(KSRC)/include
and instruct people to set the KSRC variable as needed.
[...]
Have a default value for KSRC if you need, and arrange for
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote:
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
So you're saying it's better to hardcode syscall numbers and stuff
than using the kernel headers? Sre...
Ben Collins [EMAIL PROTECTED] wrote:
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote:
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
False. That is the very thing I want to alleviate (people using kernel
On Sat, May 05, 2001 at 09:40:40PM -0400, Ben Collins wrote:
Personally I think you're trying to solve a problem that will become a
non-issue as people realise this and stop using kernel headers.
That's wishful thinking, but I agree. I'm not sure it is possible
though.
I'm more
On Sun, May 06, 2001 at 09:46:32AM +1000, Herbert Xu wrote:
The point here is to make packages start moving to Build-Dep'ing on
kernel-headers-* packages. The question is, how to allow them to do that
easily.
Personally I think you're trying to solve a problem that will become a
48 matches
Mail list logo
