Re: Bug#346281: Proposal to solve this to everyone's convenience
On Wed, 11 Jan 2006 15:16:54 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
> On Wed, Jan 11, 2006 at 07:49:04AM -0600, Manoj Srivastava wrote:
>> Err, this is additional complexity, and for what benefit? I still
>> have seen nothing that explains what we gain from the headers
>> containing the link. What is the use case? How is the link used?
> 1) you have no header or image package, there is no link.
> 2) you have no header or image package, but built your own kernel
> without k-p, and installed it, the link is there and points to
> your sources.
> 3) you have no header, but a self compiled image package, this
> package postinst checks that the build dir exist (you are on the
> same machine you built from), and sets the alternative if it is
> there.
How the hell do you know where the build dir is? It can be
anywhere on the file system. So this fails. The reason we ship the
link in the image package is that link can't easily be determined
post priori.
> 4) you have no header, and an official image, there is no link.
> 5) you have a header, but no image package, the link is set to the
> header provided dir.
Why? Anyone who wants to use the headers provided by the
headers package must sent an env var, anyway, so why not just set the
var to /usr/sr/linux-header-foo? What is the benefit of this symlink?
> 6) you have both a header and a image package, but the image package
> provides no link (either because it is an official package or
> because the build dir is missing), the header package provide his
> link.
> 7) you have a header and an image package, and the image package was
> installed before the header package, and you have the build tree
> around, so there is a link provided by the image package. The
> alternative > mechanism will see that the header has higher
> priority, and use the header link. The user can override this is
> he wants to with the alternative handling tools.
> 8) you have a header package installed, and install an unofficial
> image package which has a valid symlink to the build
> directory. The alternative mechanism will make sure the header
> symlink takes priority, and everything is fine.
We do all this in kernel-package now without the complexity of
using alternatives. Why should we add that, if there is no benefit?
> You could even imagine a debconf question of medium or low priority
> tied to the image package, and triggered if the build directory is
> valid, which would ask if you prefer to use the header symlink or
> the build one or something.
Added questions, when we can do without them, must be avoided.
> All in all, this is a rather good idea, it uses a known and proven
> tool (alternatives), will do the right thing in all cases, and will
> allow the user the choice in the two cases that matter.
But the solution now does all this and does need the added
complexity. What is the tangible benefit of having the headers always
ship a build link?
> You can even remove all special casing for official images, if you
> point the build dir to a directory which is known not to exist, or
> if the official build process sets it to <none> or some such value.
There is already no special casing for this right now, so that
is no benefit.
> I like the idea, and it should solve this once and for all to
> everyone's satisfaction, i believe :)
Well, I am not sure we have established that the benefits
justify the change over to alternatives, and how to support the end
user who just builds an image and installs it on the same machine.
manoj
--
"If I were to awaken after having slept for a thousand years, my first
question would be: Has the Riemann hypothesis been proven?" - David
Gilbert
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: