> 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 - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
