[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: linux-image-2.6.39 not booting due to older package (not in list of dependencies!)

On Tue, Aug 2, 2011 at 2:05 PM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:

> now, i've discussed this on the bugtracker and there clearly isn't -
> and really shouldn't be - a listed debian dependency between
> linux-image-2.6.39 kernel and a userspace library.  however, there
> clearly *is* a dependency because "It Don't Wurk (tm)".
> so the issue is: how the bloody hell should this clear dependency be
> expressed in "Debian Dependency" terms, such that nobody else runs
> smack into this same issue?

 ok i spoke to phil hands, and asked his advice: apparently there's
something called "Breaks:" which would do the job.

 this fulfils the requirements, namely that if you haven't got the
package installed, it's irrelevant, but if you have, then the version
must, clearly, be greater than N in order to work.

 thus, it would appear to be the case that the *older* libdevmapper
library must have "Breaks: (< linux-image-2.6.39)" and this will force
the installation of the newer libdevmapper *before* going ahead with
the installation of linux-image-2.6.39.

 why must that be the case?  very simple: if libdevmapper happens to
be upgraded at the same time, and happens to get unpacked *after*
initramfs-tools gets triggered [in the postinst?], then you have the
nasty situation where the new (correct) library is correctly
installed... but it was the *older* libdevmapper that was dropped into
the initrd at the time of the 2.6.39 kernel upgrade.  and that's known
to be "Bad (tm)".

 the other nice thing about "Breaks:" is that it's the opposite of
"Conflicts:" i.e. if you were to use "Conflicts:" it would have to go
into the linux-image-2.6.39 package, and that would be just a bit...

@begin ot
[plus, ben has completely ignored that he's been terribly insulting
and believes that my responses pointing this out are themselves in
fact insulting, and that all this ego insultingness including saying
"you are a complete liar, your bugreport *must* be worthless" is
something that justifies completely ignoring any further input, which
is, itself insulting to say the least.  thus, any further input from
ben cannot be expected, and thus the way to fix the issue is to go
from the "other end" i.e. fix the issue using "Breaks:".  *sigh*.  i
really must actually try acting like the egofuckingmaniac that people
believe i am, one of these days.  perhaps if i pointed out more often
that peoples' behaviour is very insulting rather than assuming that
they know that, things would go a bit smoother.  trouble is that i
just don't notice the things that other people would, ordinarily, be
completely outraged by, consequently get blamed rather a lot for being
pathologically honest and blunt.  oh well.... let's stop here, eh?]
@end ot

 also it's not entirely clear (whereas "Breaks:" definitely is) that
the use of "Conflicts:" would trigger a complete upgrade of
libdevmapper before proceeding with the installation of the 2.6.39
kernel (or more to the point, proceeding with the initrd recreation).

 perhaps somebody with a bit more experience of how "Breaks:" and
"Conflicts:" work would like to comment, thus ensuring that this issue
is resolved in the best possible way for the benefit of the debian
free software community? (*)


(* i.e. ignoring that the report is coming from someone whom many
debian developers feel is an "aggravating little shit who needs taking
down a peg or two by deliberately seeing the absolute worst in
whatever they write in order to *deliberately* create situations where
afore-mentioned little shit can be proven wrong har har", because this
particular aggravating little shit can in fact take care of his own
system, whereas there are many debian users who, when presented with
this same issue would find themselves completely lost)

Reply to: