libretools: don't rely on expac for blacklist-get-rep
when building packages, libremakepkg makes use of pkgbuild-check-nonfree to determine whether the package that is going to built has known freedom issues. If issues are found (known non-free license, blacklisted without replacement, ...), libremakepkg will refuse to build the package.
pkgbuild-check-nonfree uses blacklist.sh in librelib to perform the check. To determine whether a package is blacklisted, it parses the blacklist and looks for a metching entry. If there is a matching entry, the package is considered nonfree, and unbuildable, unless a liberated replacement exists.
To check whether a replacement exists, it parses the expac output for all provides and replaces in the repos, and if a match is found, the build can proceed.
This is problematic in cases where you try to build a libre replacement for a package that is already blacklisted, because the entry in the blacklist already exists, marking the package as unbuildable, but expac can find no matching replacement.
The change I propose here, is to have pkgbuild-check-nonfree, and by extension blacklist.sh check the second field of the blacklist instead of the expac output to determine not whether a libre replacement exists, but whether one is supposed to exist, and decide based on this.
Additionally, while we're at it, we should add a check that prints a warning if the blacklist entry has no associated ticket number, so that these are more visible and can be fixed as we go.
(luke, I'm setting you as the owner of this ticket, since you have the most code ownership in libretools from all of us, but this is something we can all discuss together)
Updated by bill-auger 11 months ago
i would say yes, the ticket reference should be a pre-requisite before adding anything to the blacklist, so that would be a good thing to check - to be clear though, the reference ID is not always a number - the libreplanet references are HTML anchors
regarding field 2, it would probably need to be specified as part of the blacklisting protocol1, to be sure to add field 2 before attempting to build the replacement, to avoid any transitional period where the blacklist entry is added without a replacement noted in field 2, for example when no known liberation procedure has been found yet