Re: bcc dpmi ver1.2.0

James B. Hiller
2004-06-15T03:00:38Z

> intent). It is fortunate that the bad old days of /usr/include/linux ->
> /usr/src/linux/include are mostly gone, but some systems still do that
> anyway (Slackware?).

FWIW - to be precise, Slackware isn't doing what's illustrated above,
exactly. No symlink at all. Rather, /usr/include/linux, if populated
at all, comes only from the kernel-headers package, and is a complete
copy of the kernel headers that are packaged with the kernel source
in that particular distribution.

I suspect the rationale for this would go along the lines of:

"If you want /usr/include/linux populated from this distribution, I'm
going to populate it with the headers from the (stable) kernel version
that I'm giving you. I do this with the assumption that when you change
slackware versions, you're going to do a wholesale replacement of
EVERYthing. I further assume that if you plan to chase the kernel
and be building your own, you know enough to NOT install the
kernel-specific headers here. So for these reasons, I give to the
person who's going to keep a static configuration those elements that
are internally self-consistent; and for the person who isn't, don't
install the kernel-headers package - you know what you should be doing"

I'm not saying that this makes it right, or even ok; only that it's not
the symlink situation. I'm inferring that a packaging decision was
made deliberately to fit a theme: the distribution will go as far is
it can to protect the novice from himself, but it's flexible enough to
be used by a virtuoso without extra work, and if one is a virtuoso, s/he
will know what to do with this anyway.

Reference: Slackware 9.1, and probably many earlier.

Just my 2c.

jbh