Re: build depends on kernel-headers
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 full linux headers, though I do see Ben's point in reducing the usage of non-standard headers. Sam there may be other things happening as well related to these issues. Sam If this has the net effect that I as an end user find I can't build Sam significant sets of software on Debian without significant effort, Sam but I can build the same software on a distribution that isn't as Sam agressive at being correct with its libc, then we have not served our Sam user community. We do need to encourage people to transition, but we Sam do not want to do so in a manner that causes people to get the Sam impression that Debian is less functional for their needs. I would lean towards correctness rather than popularity. If I wanted a popular, shoddy system, I would stay with windows. If people are going to be making decisions on shallow reasons like those you menti0on, I am not sure I want them using Debian; our support structure is trained enough as it is. manoj -- I'm thinking about DIGITAL READ-OUT systems and computer-generated IMAGE FORMATIONS ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 a Manoj process by which you inform make where the relevant kernel Manoj headers are to be found. make-kpkg automates that somewhat Manoj (and make-kpkg can be used for packages that are not Manoj kernel-modules, you know). Sam How do I use make-kpkg to build modules with a kernel headers Sam package? As you can see above, I never said kernel headers *package*. I reiterate, we have a process for modules that need kernel-headers, and that is provided by a process similar to the one employed by kernel-package (using kernel sources). It is trivial to create a script that will work with kernel-headers as well. kernel-package was designed to work with kernels and kernel modules, and for these one generally needed to configure the kernel locally (most modules have to be turned on during configuration). I am not saying we do not need to facilitate third party software that requires kernel headers to build. I am coming out in strong objection to the symlink shennanigans we have gotten away from in the past, for precisely the reasons we got away from them in the first place. For a developer packaging a package, it is a trivial effort to allow for a location to be provided either on the command line, or a envritonment variable, (perhaps looking at a few ``standard'' locations first. We can even have the config process ask the developer, as vmware does when compiling its modules. manoj -- It's a good thing we don't get all the government we pay for. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 than other distributions. If other distributions are still making headers available in such a way that existing software builds, and we do not, then we make lives harder for both our users and maintainers. Yes, it may be more correct, but we need to be carefule not to correct our users into frustration. Managing careful transition plans is also an important part of correctness. Herbert This is not something that we're doing. This is a Herbert decision taken by the upstream kernel maintainer(s). First, it wouldn't be the first time that we had to jump through extra hoops to make upgrading easy simply because an upstream didn't do their job right. However, I don't think there's anything we can really do in that part of the problem space. We are making active decisions related to this problem. Ben is actively removing headers not used by libc6-dev; there may be other things happening as well related to these issues. If this has the net effect that I as an end user find I can't build significant sets of software on Debian without significant effort, but I can build the same software on a distribution that isn't as agressive at being correct with its libc, then we have not served our user community. We do need to encourage people to transition, but we do not want to do so in a manner that causes people to get the impression that Debian is less functional for their needs.
Re: build depends on kernel-headers
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 than using the kernel headers? Sre... 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 a Manoj process by which you inform make where the relevant kernel Manoj headers are to be found. make-kpkg automates that somewhat Manoj (and make-kpkg can be used for packages that are not Manoj kernel-modules, you know). How do I use make-kpkg to build modules with a kernel headers package? I don't see how to do this in the manual, and when I try obvious things I get told that the kernel headers directory is not a kernel source directory. If you had said that we have a process for building modules from kernel sources I'd agree with you, but currently I don't think we have such a process for headers.
Re: build depends on kernel-headers
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! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 local header is sufficient.
linux/blkpg.h
Doesn't seem to be used?
linux/types.h
The same types are available from glibc.
linux/major.h
Local header.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 these programs harder to build on Debian than other distributions. If other distributions are still making headers available in such a way that existing software builds, and we do not, then we make lives harder for both our users and maintainers. Yes, it may be more correct, but we need to be carefule not to correct our users into frustration. Managing careful transition plans is also an important part of correctness.
Re: build depends on kernel-headers
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 process for packages that actually Manoj do need kernel headers, and are thus dependent on Manoj particular kernel versions. Sam We do? please explain what it is. We call these packages kernel modules; and we have a process by which you inform make where the relevant kernel headers are to be found. make-kpkg automates that somewhat (and make-kpkg can be used for packages that are not kernel-modules, you know). A modification of this process would be possible; but I reietrate that any package that can not deal with the headers in /usr/include/linux is very closely dependent on kernel structures, and would need to ensure that the kernel-version running has the non-public API that it depends on. Sam Herbert produces kernel headers packages for all flavors of Sam kernels he produces. I do not believe the other arches do this. This is not relevant. Out of curiosity, apart from linux/autoconf.h; what is the difference between the header packages on i386? manoj -- Nuclear war would really set back cable. Ted Turner Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 guaranteed to get the prefered kernel headers for your program (be it a scsi level thing like cdrecord, or mount tools like util-linux). The source of those userland programs should come with a copy of the required kernel headers, or with its own private definitions of the kernel interface being used. At least I understand that is the consensus on linux-kernel nowadays Mike.
Re: build depends on kernel-headers
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~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 headers
available in such a way that existing software builds, and we do not,
then we make lives harder for both our users and maintainers. Yes, it
may be more correct, but we need to be carefule not to correct our
users into frustration. Managing careful transition plans is also an
important part of correctness.
This is not something that we're doing. This is a decision taken by the
upstream kernel maintainer(s).
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 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 kernel-headers-X.X? Hmmm... -itai
Re: build depends on kernel-headers
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 kernel-headers-X.X? Hmmm...
Yes, because otherwise your code probably won't compile.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 that header in my source rather than build-depend on kernel-headers-X.X? Hmmm... Yes, because otherwise your code probably won't compile. ... when the kernel interface changed. Now tell me what is better - the package not building with the changed kernel or not working after being installed at x*1000 machines? cu Torsten pgpoW2TD3BPmt.pgp Description: PGP signature
Re: build depends on kernel-headers
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 do, since they really are not dependent on the specifics of kernel structures, and we should discourage un needed dependency on kernel structures. 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) Now, for the 1% or so of the packages that really are wedded to kernel headers, that is correct. But then these packages should not run on n a kernel version that they were compiled for. (HINT: if your program can run on a kernel different from the one you compiled for, the chances are that you do not need specific kernel headers; at most, you need to say headers from a kernel later than blah). Sure, fine, wonderful. How do I do this, exactly? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: build depends on kernel-headers
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.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 because kernel headers are not designed
to be used in user space programs. On architectures like the alpha, there
are definitions such as current which will stop any programs that include
headers which in turn include it from compiling.
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.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 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 2.4.4 kernel headers into the package and use them? cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: build depends on kernel-headers
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 solution to copy the 2.4.4 kernel headers into the package
and use them?
It needs to be looked at on a case-by-case basis. In general though,
if you need access to something that is not provided by glibc, you'll
have to setup a local header file and maintain it yourself as new
kernel releases come out.
I wouldn't expect the Debian maintainer to have to go through this
though, as this is something that must be dealt with in the upstream
util-linux package.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 2.4.4 kernel headers into the package and use them? It needs to be looked at on a case-by-case basis. In general though, if you need access to something that is not provided by glibc, you'll have to setup a local header file and maintain it yourself as new kernel releases come out. What do you suggest in my specific case with util-linux? I wouldn't expect the Debian maintainer to have to go through this though, as this is something that must be dealt with in the upstream util-linux package. You mean every upstream source should ship it's own kernel headers? That's ugly and it reminds me that libtool does the same (every program tht uses libtool ships it's own copy of libtool) - and every time I compile a program that uses libtool under NetBSD/sparc-1.5 I must do a libtoolize --force to prevent a miscompilation of the libraries - it would be much more easy when the programs would use a locally installed libtool instead. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: build depends on kernel-headers
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 exists to keep the mighty humble. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 that have been posted here several time before? (look at README.headers in the kernel-package docs for a blow by blow account). manoj -- It's all magic. :-) --Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 kernel versions. Are you also sure you have considered the impact of using one set of kernel structures, and linking with a libc that uses perhaps an incompatible set of kernel-structures? Kernel modules are loaded into the kernel, and thus are in the kernel's context, but user space modules, linked with libc, are playing with fire when they assume that the incompatible kernel structures they have been compiled with are not going to cause problems. If your package does meet the criteria, it is extremely rare, and I do not think it is wirth the infrastructure to cater to the very few packages that shall meet these criteria. manoj -- Under deadline pressure for the next week. If you want something, it can wait. Unless it's blind screaming paroxysmally hedonistic... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 be the right solution to Adrian copy the 2.4.4 kernel headers into the package and use them? Depends on how often the structures you depend on change. I would assume that you are OK with any fairly recent kernel includes, such as those provided by libc. If not, I would expect to see util-linux-2.4.4 out there soon. manoj -- Love IS what it's cracked up to be. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
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 for kernel data structures and they
need to maintain it so that it works across kernel versions.
That's ugly and it reminds me that libtool does the same (every program
tht uses libtool ships it's own copy of libtool) - and every time I
compile a program that uses libtool under NetBSD/sparc-1.5 I must do a
libtoolize --force to prevent a miscompilation of the libraries - it
would be much more easy when the programs would use a locally installed
libtool instead.
Well someone's got to maintain the kernel/user space interface. If it
isn't glibc (which does it for most things), then it's whoever uses it.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-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 actually Manoj do need kernel headers, and are thus dependent on Manoj particular kernel versions. 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.
Re: build depends on kernel-headers
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 compiling a kernel module, then the flavoued kernel
headers packages do not exist for you, period.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 obviously weren't listening to me when I explained Herbert this in the bloat thread. If you aren't compiling a Herbert kernel module, then the flavoued kernel headers packages Herbert do not exist for you, period. I thought Manoj's comments applied to modules.
Re: build depends on kernel-headers
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 linux/major.h cfdisk: linux/unistd.h linux/types.h linux/hdreg.h sfdisk: linux/unistd.h linux/hdreg.h mkswap: asm/page.h hwclock: asm/io.h asm/rtc.h asm/cuda.h linux/version.h linux/mc146818rtc.h linux/kd.h setterm: asm/ioctls.h mount + umount: asm/types.h asm/page.h linux/posix_types.h linux/loop.h linux/nfs.h linux/unistd.h linux/nfs_mount.h swapon: linux/unistd.h pivot_root: linux/unistd.h fdformat: linux/fd.h setfdprm: linux/fd.h raw: linux/raw.h linux/major.h fsck.minix: linux/fs.h linux/minix_fs.h mkfs.minix: linux/fs.h linux/minix_fs.h setterm: linux/unistd.h cytune: linux/tty.h linux/tqueue.h linux/cyclades.h linux/version.h dmesg: linux/unistd.h cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
build depends on kernel-headers
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/src/kernel-headers-2.2.19/include in the appropriate makefiles, which is obviously not any good. The latter'll obviously break as soon as 2.2.20 comes out and 2.2.19 gets removed from the archive. Also, doesn't there really need to be some way of saying I need the 2.2 kernel headers for programs that really do? Help! :) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpvPoVB3RQiA.pgp Description: PGP signature
Re: build depends on kernel-headers
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 kernel headers all together or it will become useless with 2.4.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 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 declare dependencies on kernel-headers (= 2.2.19) or whatever. p.
Re: build depends on kernel-headers
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 declare dependencies on kernel-headers (= 2.2.19) or
whatever.
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...
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 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 to be named differently. p.
Re: build depends on kernel-headers
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: kernel-headers-2.4 You'll notice that recent kernel-headers packages provide the major.minor if the kernel version. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: build depends on kernel-headers
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 that recent kernel-headers packages provide the major.minor if the kernel version. Only kernel-headers-2.2.19-sparc (in i386/unstable) does this. Is that usable on i386? (If not, should it be arch: sparc, instead of arch: all?) In any event, how do I work out what directory to tell gcc to use? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpjor5ZTibeb.pgp Description: PGP signature
Re: build depends on kernel-headers
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
to be named differently.
Kernel-image packages need to have version numbers encoded in them so that
upgrades can happen smoothly. Kernel-headers need the version numbers as
you may have multiple kernel-images packages in the archive.
The thing is, kernel-headers should not be used at all unless you're
compile glibc, or modules. Anything else will break.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on 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 the
major.minor if the kernel version.
Only kernel-headers-2.2.19-sparc (in i386/unstable) does this. Is that
kernel-headers-2.4.* does this on i386 as well. I'll add it for the next
kernel-headers-2.2 release on alpha/i386.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote: 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 to be named differently. Kernel-image packages need to have version numbers encoded in them so that upgrades can happen smoothly. Kernel-headers need the version numbers as you may have multiple kernel-images packages in the archive. 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 headers from the libc6-dev package). 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 guaranteed to get the prefered kernel headers for your program (be it a scsi level thing like cdrecord, or mount tools like util-linux). 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 --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (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. 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 += -I/usr/src/kernel-headers-2.2/include And not have to worry about all the revisions, or detecting anything special. Xu, can this alternative system be added to the kernel-headers package scripts? Does anyone see a problem with this solution (that isn't already a problem with the current usage of kernel headers in libc6-dev that is)? Anyone got a solution for the -preX case, which would probably make this method rock solid? Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: build depends on kernel-headers
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 --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (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. How about: use 100*rev as the priority for standard kernel releases, and 100*rev+X for a -preX release and hope that there are never more than 99 pre-releases ;-) -S
Re: build depends on kernel-headers
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 kernel structures, and we should discourage un needed dependency on kernel structures. Ben People should not be using them, but if they do, they should use Ben a kernel-headers package, and not rely on the headers in Ben libc6-dev which are different on all archs, and change almost Ben every new glibc build. You are never guaranteed to get the Ben prefered kernel headers for your program (be it a scsi level Ben thing like cdrecord, or mount tools like util-linux). Now, for the 1% or so of the packages that really are wedded to kernel headers, that is correct. But then these packages should not run on n a kernel version that they were compiled for. (HINT: if your program can run on a kernel different from the one you compiled for, the chances are that you do not need specific kernel headers; at most, you need to say headers from a kernel later than blah). Ben The point here is to make packages start moving to Build-Dep'ing on Ben kernel-headers-* packages. The question is, how to allow them to do that Ben easily. Ben IMO, we can use alternatives. And it should be fairly easy And hard code paths, unfortunately. Ben CFLAGS += -I/usr/src/kernel-headers-2.2/include Ben And not have to worry about all the revisions, or detecting anything Ben special. How do I build two packages that have different kernel header requirements? Ben Xu, can this alternative system be added to the kernel-headers package Ben scripts? Does anyone see a problem with this solution (that isn't Ben already a problem with the current usage of kernel headers in libc6-dev Ben that is)? Anyone got a solution for the -preX case, which would probably Ben make this method rock solid? Yes, I do. I think a less complex solution, that does not necesitate people installing debian kernel headers packages if they already have their own sources, or to have to build the package as root Try this: suggest the kernel-headers package, and set CFLAGS += -I$(KSRC)/include and instruct people to set the KSRC variable as needed. a) I do not want to hardcode /usr/src b) I do not want to hard code official debian header packages c) I do want to be able to build modules that require different kernel headers on the same box (I have one box where I do all my kernel builds) d) I do not want the kludge that is implied in the update alternatives. Have a default value for KSRC if you need, and arrange for the buildd's to create the /default-ksrc/../kernel-headers-X.X. manoj -- Q: What do you call 15 blondes in a circle? A: A dope ring. Q: Why do blondes put their hair in ponytails? A: To cover up the valve stem. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: build depends on kernel-headers
Je Sat, 5 May 2001 11:09:20 -0400, Ben Collins [EMAIL PROTECTED] scribis: IMO, we can use alternatives. And it should be fairly easy update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \ /usr/src/kernel-headers-2.2.rev rev Where rev would be something like 19 (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. 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 += -I/usr/src/kernel-headers-2.2/include And not have to worry about all the revisions, or detecting anything special. That's a better version of what I suggested in Bug#96359, so you have my support. 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. -itai
Re: build depends on kernel-headers
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.
Re: build depends on kernel-headers
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 the buildd's to create the /default-ksrc/../kernel-headers-X.X. Why not have the default KSRC be /usr/src/kernel-headers-X.X? I think that's what Ben suggested... Also, by default do you mean set in debian/rules? -itai
Re: build depends on kernel-headers
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...
Re: build depends on kernel-headers
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
headers from the libc6-dev package).
Nope, I wasn't suggesting that people should. They should stop using kernel
header files whether it be kernel-headers or libc6-dev.
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 guaranteed to get the prefered kernel headers for your program
(be it a scsi level thing like cdrecord, or mount tools like
util-linux).
False. People should not be using kernel headers at all. Linus no longer
supports this, that is, if you do use it, you're on your own and it'll most
likely break with 2.4.
The preferred solution is to maintain your own set of headers that should
work across kernel versions.
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
non-issue as people realise this and stop using kernel headers.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 confident about it, since if they don't do this, their programs
won't compile at all with 2.4. I certainly won't be keeping
kernel-headers-2.2 around any longer than necessary.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: build depends on kernel-headers
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 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. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
