Bug 193371 - knob to force deinstall of previous version of port before building the new version
Summary: knob to force deinstall of previous version of port before building the new v...
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords: feature, needs-patch, needs-qa
Depends on:
Blocks: 194070
  Show dependency tree / graph
 
Reported: 2014-09-06 08:39 UTC by Kurt Jaeger
Modified: 2019-09-05 08:12 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Jaeger freebsd_committer freebsd_triage 2014-09-06 08:39:22 UTC 
During the tests for the upgrade of textproc/p5-YAML 0.87 -> 1.11 (PR 192727) the following problem was observed (which also happened with other ports):

The old port is splitted in two new ports (here YAML -> Test::YAML and YAM). If one tries to build the new port, it conflicts with the installed old port and
the update fails.

Currently, /usr/ports/UPDATING gets a new entry and folks have to manually
handle this case.

The suggestion is to have some knob which says: during build, the
old instance of the port needs to be deinstalled.
Comment 1 Kurt Jaeger freebsd_committer freebsd_triage 2014-09-06 11:22:55 UTC 
This is not perl-specific. There are non-perl cases with similar issues.
Comment 2 Antoine Brodin freebsd_committer freebsd_triage 2014-09-06 11:31:17 UTC 
You can use CONFLICTS for this
See x11/gnome-session or biology/p5-bioperl-run for examples
Comment 3 Kurt Jaeger freebsd_committer freebsd_triage 2014-09-06 12:04:19 UTC 
(In reply to Antoine Brodin from comment #2)
> You can use CONFLICTS for this
> See x11/gnome-session or biology/p5-bioperl-run for examples

Is there any automatism which then resolves this ? From what understand,
CONFLICTS just forces manual removal. I thought more of some knob which
says "deinstall-before-build".
Comment 4 Mathieu Arnold freebsd_committer freebsd_triage 2014-09-09 09:56:45 UTC 
(In reply to Kurt Jaeger from comment #3)
> (In reply to Antoine Brodin from comment #2)
> > You can use CONFLICTS for this
> > See x11/gnome-session or biology/p5-bioperl-run for examples
> 
> Is there any automatism which then resolves this ? From what understand,
> CONFLICTS just forces manual removal. I thought more of some knob which
> says "deinstall-before-build".

Poudriere will build ports in a clean environment, and is the way to go if you want automation.
Comment 5 Kurt Jaeger freebsd_committer freebsd_triage 2014-10-23 19:24:10 UTC 
similar effect: databases/firebird25-client, as discussed here:

https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/096083.html

and following posts.
Comment 6 Kurt Jaeger freebsd_committer freebsd_triage 2014-11-07 23:09:17 UTC 
(In reply to Kurt Jaeger from comment #1)
> This is not perl-specific. There are non-perl cases with similar issues.

Like:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192867
Comment 7 Antoine Brodin freebsd_committer freebsd_triage 2014-11-07 23:17:46 UTC 
I don't understand why you don't want to use CONFLICTS for this.
When I use ports and not packages,  I don't want packages to be removed without me knowing and accepting it.
Comment 8 Kurt Jaeger freebsd_committer freebsd_triage 2014-11-08 16:21:34 UTC 
(In reply to Antoine Brodin from comment #7)
> I don't understand why you don't want to use CONFLICTS for this.

I use portupgrade in a daily cronjob. If the maintainer of a port
knows that to build version x+1 one has to deinstall version x, then
I prefer if it happens automatically during portupgrade.

Maybe some Makefile knob that is only evaluated by portupgrade would
be sufficient ?
Comment 9 Kurt Jaeger freebsd_committer freebsd_triage 2014-11-19 21:05:59 UTC 
Another occurance: ClamAV:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195182
Comment 10 Renato Botelho freebsd_committer freebsd_triage 2014-11-21 16:47:50 UTC 
(In reply to Kurt Jaeger from comment #9)
> Another occurance: ClamAV:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195182

Clamav is now fixed (upstream and ports)
Comment 11 Kurt Jaeger freebsd_committer freebsd_triage 2015-11-18 16:15:09 UTC 
Found that there's a knob

CONFLICTS_BUILD

for this kind of problem. It does not automatically deinstalls, but
at least it explains it to the casual user.
Comment 12 Baptiste Daroussin freebsd_committer freebsd_triage 2019-09-05 08:12:09 UTC 
I do think that we shouldn't automatically remove previous versions, but only explains and let the user decide. In that area, CONFLICT_BUILD is fine with it.