On 12/21/2016 11:38 AM, Bruno Pagani wrote:
OK, that is far too long to read (only read a quarter of it, with “nice” exchanges between users, Debian maintainers and upstream dev), would you mind making me a summary (or pointing to a specific comment in the thread doing so if there is one)?
Upstream considers his software to be security-critical (fair enough, it is a lockscreen), Debian doesn't like updating things, so xscreensaver contains a vaguely threatening out-of-date warning. At a certain point, people started getting warnings that xscreensaver was out of date and "your distro packager is pathetic and horrible, don't ever use _____ (mainly Debian) because they don't ever update my software, blah blah blah" leading to worried bugreports. So they "had" to patch out the warning, and in the meantime the usual "people on the internet" took the opportunity to comment on the author and his anti-linux tendencies. The Debian maintainer also got egg on his face for not having actually looked at the source code diffs, considering how noticeable the warning was. (There was a rather lengthy comment imploring distro maintainers to be polite and leave the warning in, on account of the author strongly dislikes bugreports from people who have been mislead by Debian into running ancient versions that have long-since-fixed bugs. It really *should* have been noticed.) The maintainer was human. :)
Thanks for this, will remember it. And FS#43382 was (or even is, since it is apparently still living) quite interesting too. ;)
Incidentally, a point in Debian's favor -- they seem to be aware of how html5lib was forked, and use the bundled fork so the app works; Arch only conceded the point when the API changed and calibre's fork didn't.
That looks fine for now. And it’s probably the most only thing we can do in a reasonable time frame, since working around this in makepkg looks definitively more hard than I thought. As a matter of fact, I’ve been doing that in firefox-nightly-fr[1] for quite some time (this PKGBUILD could need some simplification now that I’ve learned much more things, will do this in my current PKGBUILD enhancement tour).
But in the case of upstream signed .dsc sums, this still require some supplemental support on makepkg side. Do you think this could be achievable easily? Even if to be honest, I’m not sure of any upstream providing such signed sums, and that would be definitively OK then to wait for actual cases to be reported before being implemented, so for now an answer on whether this would be accepted if needed for this use case would be sufficient. But that’s probably more for Allan to answer this than you. ;)
I still don't see the problem. You can *always* do whatever makepkg isn't doing yourself, as long as the .dsc source file is downloaded before *sums=() is sourced. Yes, it is still an ugly hack and not really supported, but the hack should work...
Yes, and don’t you think that allowing easy verification of .dsc file would be nice (i.e. without having to code it in a prepare{} function or the like), even if the parsing and downloading of the sum file is still to be handled by the maintainer in the PKGBUILD? Again, just wanting to know whether that would be accepted in case of need, but since I, at least, have none at the moment, there is no urge in implementing this unless someone actually comes in with a lot of reported cases.
If makepkg were going to support it at all, it wouldn't be halfway. End that train of thought. -- Eli Schwartz