Re: Debian conflicts with FHS on /usr/include/{linux,asm}
Daniel Quinlan wrote:
> Raul Miller <rdm@test.legislate.com> writes:
>
> > Personally, I think that aspect of the FHS is broken, and that we
> > should talk to them about the issue they raise in the rationale:
> >
> > It is important that the kernel include files be located in
> > /usr/src/linux and not in /usr/include so there are no problems when
> > system administrators upgrade their kernel version for the first time.
>
> Yes, it used to be the case (quite a while ago) that you wanted the
> current kernel headers, but it's no longer a requirement. I'll make
> sure this gets fixed before FHS 2.1 is released.
>
> Should we continue to require that /usr/include/{asm,linux} be present
> (on systems including a C or C++ compiler) without specifying the exact
> implementation?
Another item that cannot be "fixed".
If a user wants to build a program for the current system, then the include
files should be found in /usr/include. If the objective is to built something
that will run under the next (or a future, or even a back) kernel, then
the specific kernel include files must be used.
In other words, users have only one choice, they are either naive or know
what they are doing, and in the latter case they must adapt their makefiles
to fetch the "right" include files.
The same is true for system administrators, they should not install a new
kernel without installing new include files. One way to do this is to make
links:
/usr/include/linux -> /usr/src/linux/include/linux
/usr/src/linux -> linux-x.y.z
On systems where the administrator is "the" end user this makes little
difficulty, there is a "race" condition between the time the administrator
sets the link /usr/src/linux and the time the new kernel is installed,
but that does not pose problems for the end user, who is busy building
the new kernel during that time ;-).
But on machines where a system upgrade needs to be announced on tablets of
stone several weeks in advance of the event, such links are just not on.
All systems strive to support bugs (or "features") of earlier versions,
and Linux has a good track record on that score, even though one of the
consequences of the development model is that incompatible improvements
can be made much more easily. This is a strength, as it avoids fossilizing
the system, as long as this freedom is used conscientiously.
Thomas
* Why not use metric units and get it right first time, every time ?
*
* email: cmaae47 @ imperial.ac.uk
* voice: +44 20 75 94 69 17 (day)
* fax: +44 20 75 94 69 58
* snail: Thomas Sippel - Dau
* Linux Services Manager
* Imperial College of Science, Technology and Medicine
* The Center for Computing Services
* Exhibition Road
* Kensington SW7 2BX
* Great Britain
Reply to: