Bug 193371

Summary:	knob to force deinstall of previous version of port before building the new version
Product:	Ports & Packages	Reporter:	Kurt Jaeger <pi>
Component:	Ports Framework	Assignee:	Port Management Team <portmgr>
Status:	Closed Works As Intended
Severity:	Affects Only Me	CC:	garga
Priority:	---	Keywords:	feature, needs-patch, needs-qa
Version:	Latest
Hardware:	Any
OS:	Any
Bug Depends on:
Bug Blocks:	194070

Description Kurt Jaeger freebsd_committer

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

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

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

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

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

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

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

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

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

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

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

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

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.