On 01.06.2012 18:42, Dmitry Smirnov wrote: > Hi Michael, > >> Dmitry, your two changes, both marked as fixing #674391, >> are wrong and needs revered. >> >> First, a small thing, the kmod change, >> c6ac061e12208cdf32291223b27caeefec6ce241. >> Here's the changelog difference from it: >> >> [Dmitry Smirnov] >> - * update upstream patches to avoid patching 'configure' (Closes: #674391) >> + * added 'kmod' to Build-Depends to fix FTBFS (Closes: #674391) >> + * update upstream patches to avoid patching 'configure' >> * use 'autoconf' to regenerate 'configure' >> >> Now please tell me how this kmod thing is relevant for #674391? > > Please feel free to undo my latest change introducing 'kmod' to Build-Depends. > > Initially I thought I already fixed #674391 but today when I was > building in pbuilder there were FTBFS. I did not tracked it to your > change and thought that I could have been wrong regarding diagnosis of > reported FTBFS' cause and that it was related to recent changes in > 'sid'. (It would be nice if you try to avoid breaking master with > incomplete commits or mark them as such) > I realised that this change was unrelated from one of your earlier > emails and since I already mentioned to you what I did I thought you > would realise what's happened.
Ok. Asi I said, this was a minor thing, confusing but minor -- misplaced Closes: comment. >> And second, the more serious change, which actually tries to >> fix the FTBFS mentioned in #674391. > > Not 'tries' - it fixes it. > > >> You took a wrong approach with this, by taking patches from >> upstream and removing patching of configure. This way, we're >> patching upstream patches, the result is a unverifiable mess. >> (Why upstream keeps configure in git is another question, to >> which there's no sane answer). > > Wait a sec., before criticising, consider that we don't have to patch > with pristine patches. I'm not sure why do you call it 'unverifiable' > - I'm quite concerned regarding not having hack-ish workaround for > upstream mess. > > Removing junk from upstream patches reduces the size of archive and > allows us to have nice and tidy packaging. I worry not at all about sizes of archive at this level. The "junk" you removed takes so tiny fraction, especially in compressed form, it is not even funny to mention that. But the thing is: what you call "junk" is what the upstream author applied. Yes patching configure or, generally, keeping all these generated files in git is not a good idea, and should be addressed upstream for sure. But you took upstream patches, and please respect their authorship. Once you modified these, they're not upstream anymore, and their origin is unclear. Now I looked at the upstream patches and I have strong feeling that these must be regenerated to at least include git hashes from upstream repository, -- this is what i call "verifiable". When the amount of patches grows like this, and they are being modified here and there, it becomes impossible to understand what actually changed, ie, auditing the resulting mess is almost impossible. I can partially understand such a situation when one need to backport a later patch to earlier source, and it _has_ to be changed since the code in earlier version was different. But such a backporting best be keept at minimum, maybe for only critical changes. You, instead, takes upstream patches directly, there's just no _need_ to modify them to start with. 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. > I was experimenting with different approaches for hours and what I did > is the clean and nice alternative to some other things I tried. > Why do you protect those junky hunks in upstream patches?? These junky hunks is what upstream have. >> The proposed by Dmitrijs approach -- using dh-autoreconf or >> similar, plus maybe patching Makefile to not remade configure.in >> (which is another strange thing to do) -- is the way to go here. >> dh-autoreconf will save all autoconf-related files and will >> restore them in `clean' target, making whole thing working. > > We can do it, but it would be nice to discuss why it is better (if it is). > At the moment I do not like this approach. > > dh-autoreconf is great and I use it in some of my packages but here it > looks like it would be unnecessary overkill just for the sake of > having dirty patches for generated files. 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. 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. 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!), 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. 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. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
