Date: Sat, 16 Jan 2010 07:00:15 -0500 From: "b. f." <bf1783@googlemail.com> To: freebsd-questions@FreeBSD.org Cc: dougb@FreeBSD.org Subject: Re: Dislike the way port conflicts are handled now Message-ID: <d873d5be1001160400r6c2b8df8i1fae929b3c153780@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be1001160400r6c2b8df8i1fae929b3c153780>