Re: git: 00e15405660f - main - textproc/html2text: Update CONFLICTS

Am 27.10.21 um 11:00 schrieb Alexey Dokuchaev:
> On Wed, Oct 27, 2021 at 08:41:21AM +0000, Stefan E??er wrote:
>> commit 00e15405660fffeb44772bd58ff17e841d71729b
>>
>>   textproc/html2text: Update CONFLICTS
>>   
>>   The CONFLICTS definition did only match conflicting packages built
>>   for Python-2.7, not for later Python versions.
>>   
>>   I have not checked whether CONFLICTS_INSTALL would suffice as used
>>   in the conflicting ports. The PORTREVISION has not been bumped since
>>   this parameter is relevant for port building, less so for installing
>>   from a package (which detects the conflicting files).
> 
> Somewhat surprisingly, CONFLICTS are not recorded in package manifests;
> given the existence of `pkg_conflicts' table in /var/db/pkg/local.sqlite
> which is always empty, it was probably planned, but never implemented.

Yes, a few parameters have been prepared for inclusion in the manifests,
but not implemented.

The pkg query command compares the file list with the list of installed
files registered in the package database. Additional conflicts checks
based on package names could somewhat reduce the cycles spent in the
(unlikely) case of a conflict, but the file collision check will have
to be performed anyway, therefore there is little gain to be had ...

>> ...
>> -CONFLICTS=	py27-html2text-[0-9]*
>> +CONFLICTS=	py*-html2text-[0-9]*
> 
> I recal, last time I've tried to specify a conflict without the -[0-9]*
> suffix and it worked as expected.  Are those really necessary in default
> "all versions" case?

Yes, I have considered scanning all ports for redundant -[0-9]* endings
of CONFLICTS entries.

The test performed is (with pkgbase="%n", pkgname="%n-%v"):

 fnmatch(conflicts_pattern, pkgbase) || fnmatch(conflicts_pattern, pkgname)

(This assumes that the -g option is used, exact matches or re-matches are
also possible, but the conflicts checks use a file glob match.)

Only if the package name without version number matches the pattern (with
implicit anchor at the begin and end of the pattern), an attempt is made to
match the full package name with version.

Another clean-up that could be made is to match CONFLICTS entries of all
ports against each other.

There are cases where port A is specified to conflict with port B, but the
reverse direction is not specified. And quite a few CONFLICTS specifications
should actually be CONFLICTS_INSTALL. But it takes a lot of work to check
whether there really is a build conflict for each of the combinations ...

Not supported is a CONFLICT of the type "conflicts with installed package"
to specify that a package has to be de-installed before a new version can
be built on the base system (e.g. because header files in $LOCALBASE are
used in preference of the new version's headers in the port's sources).

Currently no conflicts are detected between ports that are built from the
same port directory. This makes entries that are meant to protect against
attempts to install a conflicting flavor of a port void.

E.g. the different flavors of the devel/git port (default, lite, svn, ...)
conflict with each other, but this is not detected by the framework since
they are all built from devel/git and conflicts between ports built from
the same port directory are suppressed in bsd.port.mk. (I have a review
open that fixes that issue, see https://reviews.freebsd.org/D31151 ).

The reason for the same-origin exclusion is that there was a time when the
different flavors could have identical basenames (e.g. py-setup-... for all
packages, while now py36-setup-..., py37-setup-... etc. are enforced).

Regards, STefan