Hi, Seems like we perfectly misunderstood each other. :)
On Wed, Jul 26, 2017 at 12:31:39PM +0100, Chris Lamb wrote: > > I have to say, the moo change was entertaining, but while I see why > > someone might want that [0], I fail to see how that effects > > reproducibility of anything. > > I worry that you have misunderstood my bug report and patch. As I > mention in the initial report, it was actually raised by a user who > explicitly expressed a need and/or desire for it and they have > subsequently thanked me for taking the effort to work on fixing their > issue. Do'h. hackernews references fail for me as they (as so many sites) are annoying via tor (and was offline at time of reading), so my feeble overprotective brain skipped over it… add that it is usertagged as reproducible-builds and you get someone really confused in return. Still, I don't see a big issue – or perhaps I see it as the biggest issue that apt-ftparchive is used as you have yourself noted in the thread "So many tools to do the same thing" and apt-ftparchive is pretty old and low-level in this sea of options. As noted in the P.S. the indexes can always be post-processed with apt-sortpkgs which gets you reproducible indexes far better than sorting by filepaths will, as the later can be effected by locale and is a (probably very small) price maybe not everyone wants to pay. Especially if an explicit order was already defined by a file list. > I was also disappointed to read that you — or anyone — might think that > my position as the current DPL would have any standing whatsoever on > the applicability of bug reports or technical issues. That makes two then, as that would indeed be a lousy argument. Hence me asking why, ignoring that it was already provided, but skipped over. Still, for most bugs I would prefer if the actual user is reporting them rather than a proxy (DPL or not) and without external references simple because it is easier to justify working for a user who went through the trouble to report a bug. Perhaps it helps a bit if I explain a bit where I am coming from: apt-ftparchive is in pretty low-maintenance mode from our side, basically just ensuring it isn't breaking too hard for the few existing users. And with users I mainly mean launchpad which seems to use the libdb part nobody else does, our testcases which use 'generate' and many homegrown scripts. The later group would usually be better of using a different tool, but doesn't for various good or less good reasons (none mentioned in the thread). At least the first two aren't effected as they use filelists. A good part of the last group isn't effected either – so I wondered if someone is actually really benefiting from this or if its just asked for "because" like https. Henry Ford maybe said "If I had asked what they wanted, they would have said 'faster horses'". We could be sorting the output, but a user wanting that could have that already now with apt-sortpkgs instead of waiting 2+ years for it (= optimism, archive builders tend to be very slowly updated, which makes the feedback loop if we break something so tiring). And if a more integrated feeling is wanted, perhaps apt-ftparchive isn't the tool the user is looking for in the first place (compare 'faster horses'). So yes, I still wonder why and if its a worthwhile time investment for us as well as for the user to work on/use apt-ftparchive – and as said style issues with the patch and the problem that it effects filelist which it shouldn't. Lastly, we have basically no test covering this which conflicts with the no-new-untested code rule we try to enforce meaning yet more work. (Then again, in the time I wrote the mails, I could have probably just written a few alibi tests and fix the patch, … oh well.) Best regards David Kalnischkies
signature.asc
Description: PGP signature
