Hello Gaudenz Steinlin! On Mon, Feb 02, 2015 at 10:25:07PM +0100, Gaudenz Steinlin wrote: > > Hi Andreas > > My NMU was in no way meant to critice your maintenance of util-linux or > to attack you. It's just that in the current phase of the release > process it's time to fix these bugs and my aim is to help with that. As > you stated that you are not very motivated to work on this bug I thought > you would appreciate this help.
I absolutely appreciate that you're interested in working on this and I in no way see it as a critisism of my work. If my replies sound harsh and annoyed it's only because I'm busy and low on both motivation for Debian-work and low on energy. Please don't let that distract you. Please try to help dig through what I'm saying for the point that is technically adressable. I'm sorry I'm not better at english which is a limiting factor for me being able to express myself more clearly. Hopefully what I write gives you some clues to what issues I might have spotted. > > Andreas Henriksson <andr...@fatal.se> writes: > > > Hello Gaudenz Steinlin. > > > > On Mon, Feb 02, 2015 at 11:25:55AM +0100, Gaudenz Steinlin wrote: > >> Of course a fix in util-linux can't solve problems resulting from other > >> packages. All packages that call update-initramfs and don't depend on > >> initramfs-tools need the same Breaks relation to live-tools. I don't > >> know how many other such packages exist beside util-linux. > > > > Easy to find out thanks to the awesome codesearch: > > http://codesearch.debian.net/perpackage-results/update-initramfs/2/page_0 > > (Adding regexps to the query for filtering out only relevant matches is left > > as an exercise to the reader.) > > > > In other words, many.... That is why adding breaks IMHO is not a > > viable solution at all anywhere. > > That does not really help much because we don't need a list of packages > that mention update-initramfs in some file but a list of packages that > call update-initramfs in their maintainerscript without depending on > initramfs-tools. I don't think codesearch is able to produce that list, > but to me this seems like a quite special case. I would expect most > packages that modify the initramfs to actually depend on > initramfs-tools. > > But I agree that probably more packages than just util-linux need fixing > for this. But this is outside the scope of this bug and as long as no > other bugs are filed, it's hard to track. I also don't see a viable > solution to this bug which fixes all of these problems in one go. I guess we just have to agree to disagree. In my point of view sweeping symptoms under the carpet is not the way to go to call something "solved". The problem is not in util-linux to start with and if we can't solve it in the actually buggy package then we should alter all the ways to trigger it, not just one. I also think it's better to just drop the update-initramfs call instead if we're going down that path anyway (as the reason it was added does not apply to jessie). > > >> I agree that fixing the problem with Breaks is a bit ugly and in theory > >> adds the fix to the "wrong" package. But I currently don't see any > >> viable other solution to this problem beside adding all these Breaks > >> relations. An update to the stable version of live-tools does not seem > >> practical to me. Do you see another way to fix this? > > > > Yes. Please read my previous mail to the bug report. > > So if I got you right, you would prefer to remove the update-initramfs > call from util-linux's postinst. I'm fine with that. I can do another > upload if you confirm that's your prefered solution. If initramfs-tools > from current unstable really does not go into testing, then I agree that > is probably the slightly better alternative. > > To me as an NMUer the Breaks seemd like the safer option as it's a no-op > as long as live-tools is not installed on the same system. So there is > less chance that the NMU breaks something. Right. I hope we, during the next development window, make sure initramfs-tools stops pulling in parts of util-linux into the initramfs. From what I've heard, the reason is that fsck does timestamp checking which other distributions has simply patched out to not have to deal with timezones in initramfs (or something like that -- don't remember exactly). > > >> > >> > > >> > This is just one example out of several problems I see with your NMU. > >> > >> Which other problem do you see? > > > > Well, for one: > > Your NMU is RC buggy, given that you incorporated the previous NMU with > > bugs and all. Thanks for taking responsibility for that. ;) > > Well for one it was not my upload that introduced this RC bug. The > version of the previous NMU was already in *testing* when I did my > upload. IMO we are all colectively responsible for getting the jessie RC > bug count down. So it's as much my responsibility to fix this as yours. > ;-) :P > > But if I do another upload I will also fix the typo in the 4.1 NMU. I > missed the fact that the 4.1 NMU did not fix the bug it claimed to fix. > > > > > Please, again, also read my previous mail to the bug report you're > > trying to fix and you'll find a similar but IMHO much more valid reason > > to add a Breaks for another package (which is also that packages bug and > > not a bug in util-linux). > > I don't understand what you mean here. Maybe you should be a bit more > explicit in your message instead of alluding to what others should do. > > > As you probably understand, I'm trying to urge you into looking at the > > whole picture instead of just a tiny part. That way I'm sure you'll > > likely come up with much better solutions. > > I don't completely understand what you are aiming at. IMO I always > considered the whole picture but I don't see why the grml-debootstrap > issue is related. Yes it's an issue, yes it'might be solved with a > Breaks (did not look into it very deeply). But it's not about > update-initramfs and has a completely different cause. I don't see how > these two issues can be solved together. They seem quite orthogonal to > me. And last but not least the grml-debootstrap does not even have RC > severity at the moment. If you as one of the util-linux maintainers > think this is RC, please set the severity accordingly. I think the live-tools and grml-debootstrap are the same and should have the same severity. None of them are IMHO RC for util-linux as both are bugs in respective packages and not in util-linux. But if you choose to fix one, please take both. Got to run now..... Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
