Re: kernel headers
On 17 Jan 1998, Manoj Srivastava wrote:
> Semantically, you are correct. However, in practice, if
> /usr/src is where non local src code goes, then if you put local code
> there as well there is no way to avoid conflicts.Rather than saying
> that non-local code be thrown out of /usr/src; I prefer to reserve
> that for vendor code. After all, there is a well established place
> for local code to go already.
I am by no means suggesting that non-local source be thrown out of /usr/src.
That's where non-local source is supposed to go, according to the FSSTND.
The FSSTND, by design, says nothing about local modifications. The accepted
place for source code to go is /usr/src; I believe that we should understand
and accept that this practice is not going to change in the near future.
> >> Then don't complain. You break Debian policy on your machine (as
> >> is your right), then Debian is no longer responsible for support.
>
> Avery> Just because it's not officially guaranteed to work doesn't
> Avery> mean it's not allowed to work.
>
> Huh? In this case, as you said yourself, it does not work. It
> is not guaranteed to, and it does not. Wheres the beef?
Sigh. The above statement was a generalization meant to apply if it turns
out that I was breaking Debian policy. It is still my opinion that
installing a local kernel source tree in /usr/src/linux is _not_ breaking
Debian policy.
However, my point in the quote above was that _if_ I were breaking Debian
policy by extracting the kernel into /usr/src/linux, Debian should quietly
recover. As things are, it loudly mangles things.
I maintain that it would be _EASY_ for Debian to quietly recover from this
situation: "Just because it's not officially guaranteed to work"
(kernel-headers thinks it should own /usr/src/linux) "doesn't mean it's not
allowed to work." (kernel-headers should accept that it can't own
/usr/src/linux, because that doesn't hurt anything).
> Avery> If kernel-headers would just allow itself to be configured when
> Avery> /usr/src/linux is not a link, I would be a happy camper,
> Avery> because then I could install libc6 without a --force option,
> Avery> thereby validating my existence. Nothing imaginable would
> Avery> break.
>
> Sorry. I do not like my code to merrily proceed when an
> invariant is broken.
To put it bluntly, we are testing for a stupid invariant. There is only one
reason that kernel-headers does not work perfectly when /usr/src/linux
already exists: kernel-headers checks to make sure /usr/src/linux does not
already exist.
That's equivalent to writing the following in the postinst for pppd:
if (cos(3.1415926535) != -1)
return ERROR;
else
// continue installation
True, cos(PI) should always be -1 (barring floating point inaccuracy), but
whether this is true has absolutely no bearing on whether pppd will work
after it's installed.
Similarly, whether the /usr/src/linux symlink exists has no bearing on
whether kernel-headers is installed correctly. All packages that depend on
it (only libc6-dev, I think) will work flawlessly with or without the
symlink.
> As to whether the user may proceed to compie with the FSSTND
> outside of Debian, I do not wish to argue with you. The user may
> choose not to install the Debian libc or make or sed too, and still
> claim to have a "normal" Linux distribution. Debian packages shall
> still fail to install correctly, if the Debian package is not
> installed.
If the user complies with FSSTND _and_ has a /usr/src/linux containing valid
header files (the only two parts of Debian policy which you have quoted me),
then the user complies with Debian policy. If the user complies with Debian
policy and has package installation failures, then something is seriously
wrong with the policy or the packages.
I am asking for the simplest of simple changes to the kernel-headers /
kernel-source install script: do not return a failure code to dpkg if the
symlink to /usr/src/linux fails. That one change eliminates the whole
problem we're arguing about, while causing no other problems.
Avery
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: