Re: omniorb debs
On Sun, Dec 09, 2001 at 01:52:48PM +0100, Adrian Bunk wrote:
> On Sun, 9 Dec 2001, Matt Zimmerman wrote:
>
> > On Sun, Dec 09, 2001 at 11:47:34AM +0000, Philip Blundell wrote:
> >
> > > In message <[🔎] 1007897758.19662.15.camel@c3po>, Tobias Hunger writes:
> > > >PS: To which severity should I set it if it's not critical? Messing up
> > > >/usr/include is more then a 'normal' bug IMHO, even if it does not break
> > > >other applications..
> > >
> > > "Serious" is probably right.
> >
> > Only if you can find a mandate in the policy manual that it violates. It's
> >...
>
> Section 10.1.1. of our policy says "The location of all installed files
> and directories must comply with the Filesystem Hierarchy Standard (FHS),
> except where doing so would violate other terms of Debian Policy.".
This is all that the FHS says about /usr/include right now.
<quote>
4.3 /usr/include : Directory for standard include files.
This is where all of the system's general-use include files for the C and
C++ programming languages should be placed.
"/usr/include"
X11
bsd
g++
"Include files"
Symlink to /usr/X11R6/include/X11
BSD compatibility include files (if required)
GNU C++ include files
6.1.5 /usr/include : Header files included by C programs
These symbolic links are required if a C or C++ compiler is installed and
only for systems not based on glibc.
/usr/include/asm -> /usr/src/linux/include/asm-<arch>
/usr/include/linux -> /usr/src/linux/include/linux
</quote>
This cruft doesn't seem to be violating any of these mandates, and it
doesn't functionally interfere with anything else in /usr/include. It's
just cruft (and embarrassing cruft at that).
By now, we've spent more time discussing it than it would have taken to fix
this particular bug. I'm not in a position to tackle the real bugs right
now, though.
--
- mdz
Reply to: