On Tue, Aug 2, 2011 at 2:05 PM, Luke Kenneth Casson Leighton <luke.leigh...@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. http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks 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... weird. @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? (*) l. (* 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) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedydwrzrn-ubuixmynupb1_qcsk5ffnyb85gi44u_xg...@mail.gmail.com
