Bug#346281: Proposal to solve this to everyone's convenience (Was: linux-image-2.6.15-1-686: debconf question about /lib/modules/2.6.15-1-686 even if no kernel is installed)
On Wed, Jan 11, 2006 at 07:49:04AM -0600, Manoj Srivastava wrote:
> On Wed, 11 Jan 2006 08:52:18 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
>
> > On Tue, Jan 10, 2006 at 09:00:57PM -0600, Manoj Srivastava wrote:
> >> On Tue, 10 Jan 2006 23:53:03 +0100, Sven Luther
> >> <sven.luther@wanadoo.fr> said:
> >>
> >> > On Tue, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote:
> >> >> On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther
> >>
> >> >> > Whatever, i think the build directory should just work, and
> >> >> > that was the agreement we had back then on this. I assumed
> >> >> > this was indeed the case. Any idea what exactly is going
> >> >> > wrong here.
> >>
> >> The build directory "just works" in the common case, anyway.
>
> > BTW, what about the image and headers both providing the build
> > symlink, except for official images which will not, and using the
> > alternatives mechanism, with the header symlink having the bigger
> > priority ? This way everyone is happy, it just work, and the user
> > can even override things.
>
> 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.
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.
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.
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.
Or the debconf question could be on both the image and header, and be
triggered each time there are two possible cases for the symlink.
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.
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.
I like the idea, and it should solve this once and for all to everyone's
satisfaction, i believe :)
> > We still need to provide stong conflict between official packages
> > and compiled from random source reusing the same name.
>
> And I think this is a bug. We should be minimizing needless
> conflicts between packages, not adding them -- especially if there is
> no tangible benefit.
Well. Do you honestly claim that supporting the following use case :
The user has rebuilt a header or image package from his own sources,
possibly patched with some random ABI breaking patch, is reusing the same
flavour as the official kernels, and want to use this package together with
the official image or header package respectively.
is something worth doing ? I don't think so, and as i mentioned in my other
mail, this will cause a world of hurt and pain to the kernel team and to
whoever is in charge of stable updates for a long period of time. Don't allow
that, and altough it can always be done, don't force us to recognize this as a
valid situation.
Having the official images provide linux-official-<version>-<abi>-[<subarch>-]<flavour>
or linux-debian-<verson>-<abi>-[<subarch>-]<flavour> and having self built
kernels conflict with those is a minimum protection against this kind of
breakag, even though my above proposal removes the conflict you feared about.
Friendly,
Sven Luther
Reply to: