Bug 173620 - [bsd.port.mk] Recovery of the functionality of CONFLICTS among ports with different default PREFIXs, ex., between KDE4 and others
Summary: [bsd.port.mk] Recovery of the functionality of CONFLICTS among ports with dif...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-14 02:00 UTC by sakaue.mamoru
Modified: 2015-06-13 02:33 UTC (History)
0 users

See Also:


Attachments
file.diff (1.81 KB, patch)
2012-11-14 02:00 UTC, sakaue.mamoru
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sakaue.mamoru 2012-11-14 02:00:00 UTC
CONFLICTS, CONFLICTS_BUILD and CONFLICTS_INSTALL don't work between ports with different default PREFIXs. For example, this problem arises between KDE4-related ports and the other ports. 

The current implementation of confliction check in bsd.port.mk is based on matching PREFIXs of the installing port and installed package as well as matching of the package name pattern given by CONFLICTS, CONFLICTS_BUILD and CONFLICTS_INSTALL with installed ones.

As the original intention, this mechanism will assume that PREFIX is customized only for manual relocation of installtion paths. However this rule is practically violated by some ports like KDE4-related ones which redefine PREFIX as /usr/local/kde4 by default.

In this patchwork, I propose a change of the macthing rule in bsd.port.mk so as to make it work correctly with the default configuration of the system.

Please note that this modification makes the matching rule stricter for packages installed in environments where PREFIX or LOCALBASE is explicitly customized, for example, temporal environment in "port test" command of ports-mgmt/porttools. In that case, DISABLE_CONFLICTS may be given as a make argument for countermeasure.

Fix: The current implementation gives conclusion of a conflicting package by macthing of the current PREFIX with PREFIX registered for the package whose package name matches any of patterns in CONFLICTS* variables.

I propose a new implementation that gives conclusion of a conflicting package by macthing of the default PREFIX of the package with the registered PREFIX of the package. If the default PREFIX cannot be evaluated because of moving or abolishment of the origin for the package, the conclusion is given as true.

This solution is not fundamental as well, but makes the situation more practical.


Patch attached with submission follows:
How-To-Repeat: With qt-3.* installed, try insallation of editors/calligra which defines "CONFLICTS_BUILD=qt-3.*"

# pkg_info -I qt-3.\*                                                                                                                                                             
qt-3.3.8_14         Multiplatform C++ application framework                                                                                                                         
# cd /usr/ports/editors/calligra
# make

Then no confliction is reported and the process continues to the build stage.
Comment 1 Tilman Keskinoz freebsd_committer freebsd_triage 2012-11-21 17:06:44 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

bsd.port.mk patch
Comment 2 Max Brazhnikov freebsd_committer freebsd_triage 2012-11-22 13:58:45 UTC
I agree about proposed changes for CONFLICTS_BUILD, but not for _INSTALL.
CONFLICTS_INSTALL is intended for ports that install files in the same place.
Obviously, such ports don't really conflict when installed into different prefixes.

Max
Comment 3 sakaue.mamoru 2012-11-22 18:39:53 UTC
I agree. Then only the first half of the patch should be applied.

P.S.
I revise the last paragraph of Description:
-----------------------------------------------
> Please note that this modification makes the matching rule stricter for
> packages installed in environments where PREFIX or LOCALBASE is explicitly
> customized, for example, temporal environment in "port test" command of
> ports-mgmt/porttools. In that case, DISABLE_CONFLICTS may be given as a make
> argument for countermeasure.
===>
Please note that this modification makes the matching rule LOOSER among 
packages installed in environments where PREFIX or LOCALBASE is explicitly 
customized, for example, temporal environment in "port test" command of ports-
mgmt/porttools. Another side effect is that the matching rule becomes stricter 
for packages whose origins are moved or deleted. In that case, 
DISABLE_CONFLICTS may be given as a make argument for countermeasure.
-----------------------------------------------

Mamoru Sakaue
Comment 4 Alberto Villa freebsd_committer freebsd_triage 2013-01-09 14:22:20 UTC
> I agree about proposed changes for CONFLICTS_BUILD, but not for _INSTALL.
> CONFLICTS_INSTALL is intended for ports that install files in the same place.
> Obviously, such ports don't really conflict when installed into different prefixes.

Ports that explicitly install in a prefix via @cwd are going to fail
even with different PREFIX, anyway.
Comment 5 sakaue.mamoru 2013-01-12 10:20:09 UTC
Anyway, since PREFIX is redefined in several places of bsd.(gnustep|kde|kde4|
python).mk so as NOT to inherit the predefined value as "grand" prefix, it 
should not be recommended for users to control the installation paths by 
giving a explicit PREFIX value to a make command unless they are really aware 
of what to occur and are going to do everything on their own responsibilities.

Only LOCALBASE and LINUXBASE will be favorable for such purposes because they 
are defined in only one place at the head of bsd.ports.mk and LOCALBASE is 
inherited for the redefinitions of PREFIX. Therefore, as an ideal solution, 
the package database should record the values of LOCALBASE and LINUXBASE 
rather than PREFIX for further judgment of confliction.

I think that the current goal as a workaround should be to make CONFLICTS* 
work as intended by the specification in the default configuration.
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2014-06-02 02:48:46 UTC
Infrastructure PR.
Comment 7 Mathieu Arnold freebsd_committer freebsd_triage 2015-06-13 02:33:39 UTC
We don't support using multiple PREFIXes.