Dislike the way port conflicts are handled now

b. f. bf1783 at googlemail.com
Sat Jan 16 12:00:25 UTC 2010


On Fri, Jan 15, 2010 at 11:57:35PM -0500, Greg Larkin typed:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Craig Whipp wrote:
> >
> > On Jan 15, 2010, at 9:44 AM, Kirk Strauser wrote:
> >
> >> Until recently, it seems like port dependencies were handled at
> >> installation time. Lately, they're handled any time I try to do
> >> anything with a port. I absolutely detest the new behavior. Example
> >> cases:
> >>
> >> OLD WAY:
> >>
> >> $ cd /usr/ports/something/foo22
> >> $ make
> >> $ pkg_delete foo21-2.1
> >> $ make install
> >>
> >> NEW WAY
> >>
> >> $ cd /usr/ports/something/foo22
> >> $ make
> >> ===>  foo22 conflicts with installed package(s): foo21-2.1
> >> $ make fetch
> >> ===>  foo22 conflicts with installed package(s): foo21-2.1
> >> $ curse --type=copious
> >> $ pkg_delete foo21-2.1
> >> $ make install
> >>
> >> This isn't just a hypothetical pain in the butt. An example was being
> >> unable to build databases/mysql51-client because
> >> mysql-client-5.0.something was installed. I understand not being able
> >> to *install* it, but to be prevented from *building* it? In most
> >> circumstances, I want to be able to delete the old package and install
> >> the new one with minimal downtime. As another example, can you imagine
> >> not being able to even run "make fetch" on something huge like
> >> OpenOffice until you uninstalled the old version?
> >>
> >> In the mean time, I've been editing the port's Makefile to remove the
> >> CONFLICTS line long enough to finish building. That's not very helpful
> >> for those ports that don't actually build until you run "make
> >> install", but at least I can get the distfile download out of the way.
> >> --

Both methods have their advantages, and disadvantages.  With the old
method (deferred check), a person could attempt to install a port,
only to find that after spending a lot of time fetching, extracting,
and building the port, that it could not be installed because of a
conflict.  This can't happen with the new (early check).

Fortunately, there is a (largely undocumented) knob in bsd.port.mk
that will allow you to bypass the conflict check by defining
DISABLE_CONFLICTS in your build environment.  So it's not necessary to
edit the port Makefiles just to tinker with ports that conflict with
other, already-installed ports: simply change your second example to:

make -C /usr/ports/something/foo22 DISABLE_CONFLICTS=1
drink_beer --type=copious


> >>
> >> Kirk Strauser
> >>
> >
> > I agree.  I've found that this can interfere with portmaster's "-o"
> > option, used to replace an installed port with one of a different
> > origin.  In my case, databases/mysql41-server with
> > databases/mysql55-server.

This is more of a problem.  But the author of portmaster could put a
workaround into place.


> >
> > - Craig
>
> This change was based on a recent PR
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=137855) and made it into the
> tree a couple of weeks ago:
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r1=1.631;r2=1.632
>
> Since some folks like the old behavior and some folks like the new
> behavior, what do you all think of a user-selectable make.conf option to
> choose where the check-conflicts target appears in the port build sequence?

I think that's a good idea.

b.


More information about the freebsd-questions mailing list