Hi Michael, On Sat, 2 Jun 2012 03:20:21 Michael Tokarev wrote: > You, instead, takes upstream patches directly, there's just no > _need_ to modify them to start with.
You've made some good arguments. Just a thought: as soon as we found ourselves in need to modify upstream patches the alternative could be to consolidate them into one super-patch and drop unwanted stuff from it... I see you consolidated upstream patch set but did not drop hunk patching 'configure'. > I think you took wrong way with these patches to start with -- if > you take all upstream patches anyway, I'd have just one diff with > all of them autogenerated by git diff, without modifying the content. > But that's a different story, and _that_ is what makes the packaging > nice and tidy. Yes, perhaps we could do this. > These junky hunks is what upstream have. Unfortunately. That's why I thought it would be reasonable to modify patches and share our experience with upstream (forward). > Dmitry, this really makes me a bit concerned. This is 3rd > discussion I'm having with you. First was about keeping > upstream in git - okay, I don't want to "force" it on you > if you dislike it. Second was "wrong" approach I took with > default/autofs patch, and there we had quite hot discussion > till I explained things to you. Now it is 3rd case in a row > when you do something which, well, should not be done, and > you're arguing to death. I'm sorry that it appears like arguing to you. I think we should talk because when I did something and it works well, you don't just revert and call it 'wrong' without justification. At least you could say something like 'I think it would be better to do *** because...' - if you did, perhaps there would be no additional discussion necessary. I have no reason to argue against something better than I did. > This package is a bit difficult, partially due to inaccuracy > of upstream in using auto* tools, partially due to general > inaccuracy of source (eg, checking for modprobe in configure > and #error'ing in automount.h if not found is just wrong, > and it is especially wrong since that modprobe-calling code > isn't even used!), :( > let's not make it even more difficult. Sure. I hope we'll learn to understand each other better soon - if not I don't want to be in your way given that at the moment you're the one who work most actively on package. > Again, I care not a bit about dh_autoreconf being overkill > or anything (whole dh thig is a huge overkill, let's write > everything in assembler, sure it will be much faster!), Let's not use absurd examples please. :) Perhaps my choice of words was not ideal - I care about maintainability and you had some good arguments supporting your idea. > as > long as it helps us to have unmodified upstream patches and > be able to build and rebuild the package and apply and deappy > patches freely. Including a call to dh_autoreconf in a place > or two is much cleaner than rewriting upstream patches. True. IMHO the ideal approach would be to convince upstream to clean patches in which case we won't need dh_autoreconf. I see no reason why upstream would object so I was on that path when I decided to clean patches. By the way in the change that you reverted I did make upstream patches un- apply-able. > Having said that, I admit that --with autoreconf does NOT > solve the issue: that option _removes_ the files modified > by autoreconf run, instead of restoring them, so deapplying > patches still does not work. I'm trying to fix that right > now, with cooperation with Dmitrijs. Good luck, but I think you might be doing unnecessary work especially if we will need to drop dh-autoreconf in the future when it won't be needed any more. If such you might be ignoring my good short term solution without clear evidence that what's you're doing is going to save us any time in the future. And now as direct result of your decision we sill have un-apply-able patches. As I mentioned, we could release my fix for FTBFS and then re-factor it without rush later. But never mind, I hope you know what you're doing. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
