Bug #2187

libretools: don't rely on expac for blacklist-get-rep

oaken-source - about 5 years ago - . Updated about 2 months ago.

% Done:



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 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 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 about 5 years 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



Updated by lukeshu about 2 months ago

  • Status changed from confirmed to fixed

I'm marking this as fixed, with the changes in (included in v20240221).

Now it trusts blacklist.txt field-2 when field-2 == field-1, and uses expac otherwise.

I almost went with having it only fall back to expac if field-2 is empty. But what would that accomplish--it would only make a difference for when building a package that depends on a blacklisted package; and if expac can't find a replacement for that dep, then the build will fail anyway.

Also available in: Atom PDF