On Sat, 25 May 2019 at 18:33:55, Bruno Pagani wrote: > Well I think it should instead be used for such bugs in the case of VCS > packages, because those are the only cases where they can be OOD, and in > contrary to normal packages those are valid OOD reasons. And that is the > case for the linked package in the FS ticket. But I acknowledge this is > not what we say currently, though I would use the opportunity of that > addition to change the guidelines regarding this. And then I’m in favour > of saying so in the message: > > “This is a VCS package. Please do not flag it out-of-date if the package > version in the AUR does not match the most recent commit. Flagging this > package should only be done if the sources moved or changes in the > PKGBUILD are required because of recent upstream changes.”
That message sounds good to me. > > >>> +/** > >>> + * Determine whether a package base is (or contains a) VCS package > >>> + * > >>> + * @param int $base_id The ID of the package base > >>> + * > >>> + * @return bool True if the package base is/contains a VCS package > >>> + */ > >>> +function pkgbase_is_vcs($base_id) { > >>> + $suffixes = array("-cvs", "-svn", "-git", "-hg", "-bzr", "-darcs"); > >> What about false positives and missing items like -nightly’s? I think it > >> would be a good time to implement FS#56602, auto-seed the value > >> depending on your above list and let maintainers override this. > > Yes, there are false positives and false negatives. That is why we only > > display a warning and do not automatically disable the feature for VCS > > packages. Read the comments in FS#62733 for details. > > All I’ve read was the same thing as before regarding the impossibility > to correctly detect all VCS packages and just them, but I did not see > why manual override wouldn’t be an option. ;) Regarding false positives, > without override possibility they will be misleading to users, so I > don’t agree on “it’s OK because we are not plainly disabling the > feature”. Also for me the strongest reason to not disable the feature > for VCS packages is rather because it is still useful even for those, as > stated by Eli. :) We could tune the message and say "This seems to be a VCS package." I would prefer to keep this very simple. That message is just for convenience and not really an essential part of the AUR.