Re: Bug#346281: Proposal to solve this to everyone's convenience
On Wed, Jan 11, 2006 at 09:12:14AM -0600, Manoj Srivastava wrote:
> 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.
Because you write it somewhere doing the package build time, most probably
into the postinst file, as you do with so many other variables (the =K and so
ones)
> > 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?
For consistency's sake, and so that users can write scripts building modules,
which will not change if we modify the /usr/src/linux-header-foo path down the
road.
> > 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?
ok, then do it without the alternatives, just include the additional support
for the case where only the headers are installed.
> > 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.
Ok, fine.
> > 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?
If by now you didn't understand that, it is clear that you never will.
> > 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.
Sure there is a special casing, you delegate it to the end user though :)
> > 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.
Ok, then don't use alternatives, this method should be able to work just as
well with your custom symlink handling code, you just need to support the
additional use case of only having the headers installed, and everyone is
happy.
Friendly,
Sven Luther
Reply to: