Re: Dislike the way port conflicts are handled now
On Sunday 17 January 2010 10:24:43 Matthew Seaman wrote: Ion-Mihai Tetcu wrote: I'd be very happy if I could: - fetch the distfiles, even if I have a conflicting port installed - be able to use portmaster -o to switch from one port to an other one that conflicts with it. - be able to at least compile a port (eg. for testing) without having to de-install the current one. I'm all in favor of restoring the old behavior with a switch available to turn on the new one. +1 Although a big fat warning message at fetch or build phase when operating on a port with conflicts wouldn't go amiss. I'd agree with this too. The idea of the change seems to be to protect people from wasting time downloading and building something which they can't install without resolving a conflict. How exactly was that wasted time? Surely you don't download and build a port you're not going to install? What the change actually does is penalise people who want to download and build regardless of conflicts, to reduce the time between uninstalling the conflicting port and being able to install the replacement. This seems to me to be a very badly thought-out change which should be reverted. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
Argh! Stop! I wish that people who felt the need to add to this thread would read the prior posts beforehand, and consider their comments before posting. To answer two previous posts: I believe that he is talking about changing _when_ the check for conflicts is made; whereas DISABLE_CONFLICTS ignores the check, regardless of when it is made. A late check is preferable to using DISABLE_CONFLICTS, because with that knob you can shoot yourself in the foot by mistakenly installing one port on top of another. I think the point is you can make -DDISABLE_CONFLICTS using targets other than install ?! Obviously, you can use it for other targets. That doesn't seem to have been in doubt. The point is rather that if one disables the conflicts check and then accidentally uses the 'install' target or another target requiring 'install', and there is a conflicting port already installed, there are going to be problems. Of course that wouldn't be a good idea, but it can happen, and that is the point of having a check. -- The idea of the change seems to be to protect people from wasting time downloading and building something which they can't install without resolving a conflict. In two earlier posts, a member of portmgr@, and someone else described how the change was also meant to prevent some build errors. How exactly was that wasted time? Surely you don't download and build a port you're not going to install? A number of earlier posters have said that they want to do exactly that. I do it myself, to test ports. But one can also start with the intention of installing port A, only to later learn that it conflicts with an already-installed port B, and then, having discovered the conflict, decide not to install port A after all, in order to keep port B. In this case, which happens fairly often, any time spent before the discovery of the conflict would have been wasted. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On Monday 18 January 2010 17:48:37 b. f. wrote: Argh! Stop! I wish that people who felt the need to add to this thread would read the prior posts beforehand, and consider their comments before posting. I don't know why you assume people didn't. I read the whole thread. I saw people who had individual special requirements, but I didn't see anything that suggested I was wrong in assuming the most common use case, by far, to be downloading and building a port in order to install it. Assuming that *is* indeed the commonest use case, this change makes life a little more difficult for almost everyone in order to save possibly as much as tens of minutes of wasted time for a few people. Worse than that, the new behaviour either increases downtime (by requiring that the conflicting port be removed before even starting to download the replacement) or requires, as you pointed out, setting a risky option which if accidentally misused, could break the whole system. I still think it's an ill-considered change for the worse to make the new behaviour the default. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
Greg Larkin píše v so 16. 01. 2010 v 18:02 -0500: Here is the original post: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg227363.html I will agree that `portupgrade -o` is way too useful feature. I'd vote for reverting to the old behaviour. I thought portmgr might have some insight into additional reasons for making the change, such as fixing a problem with pointyhat builds, etc. At the moment, I'm neutral on the change, since it hasn't caused me any grief, but I did some research for the folks who posted the original questions. It was done because someone thought it is a good idea and submitted a PR about it. -- Pav Lucistnik p...@oook.cz p...@freebsd.org I can't do that, that would make sense. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: Dislike the way port conflicts are handled now
On Sun, 17 Jan 2010 11:44:05 +0100 Pav Lucistnik p...@freebsd.org wrote: Greg Larkin píše v so 16. 01. 2010 v 18:02 -0500: Here is the original post: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg227363.html I will agree that `portupgrade -o` is way too useful feature. I'd vote for reverting to the old behaviour. I thought portmgr might have some insight into additional reasons for making the change, such as fixing a problem with pointyhat builds, etc. At the moment, I'm neutral on the change, since it hasn't caused me any grief, but I did some research for the folks who posted the original questions. It was done because someone thought it is a good idea and submitted a PR about it. Howdy, For some ports is the conflict check too late see example here. http://lists.freebsd.org/pipermail/freebsd-gecko/2009-December/000577.html I agree that we need a new pre-fetch hook in bsd.port.mk if a conflict present is. But that need a bit work and it is on my todo list... - Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
Ion-Mihai Tetcu wrote: I'd be very happy if I could: - fetch the distfiles, even if I have a conflicting port installed - be able to use portmaster -o to switch from one port to an other one that conflicts with it. - be able to at least compile a port (eg. for testing) without having to de-install the current one. I'm all in favor of restoring the old behavior with a switch available to turn on the new one. +1 Although a big fat warning message at fetch or build phase when operating on a port with conflicts wouldn't go amiss. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Dislike the way port conflicts are handled now
On 1/17/10, Martin Wilke m...@freebsd.org wrote:
On Sun, 17 Jan 2010 11:44:05 +0100
Pav Lucistnik p...@freebsd.org wrote:
Greg Larkin píše v so 16. 01. 2010 v 18:02 -0500:
I will agree that `portupgrade -o` is way too useful feature.
I'd vote for reverting to the old behaviour.
portupgrade and other tools can easily be patched to work with the
new behavior, by defining DISABLE_CONFLICTS for the targets preceding
installation. Since the new behavior is generally more efficient, and
safer, and since the people who will need to defer the check for some
reason are in the minority, I vote that we keep the new behavior, and
offer a chance to opt out of it with something like the attached
patch. I didn't add any extra warnings, since I assumed that those who
choose to defer the checks already know that this may lead to problems
in some cases.
b.
I thought portmgr might have some insight into additional reasons
for making the change, such as fixing a problem with pointyhat
builds, etc. At the moment, I'm neutral on the change, since it
hasn't caused me any grief, but I did some research for the folks
who posted the original questions.
It was done because someone thought it is a good idea and submitted a
PR about it.
Howdy,
For some ports is the conflict check too late see example here.
http://lists.freebsd.org/pipermail/freebsd-gecko/2009-December/000577.html
I agree that we need a new pre-fetch hook in bsd.port.mk if a conflict
present is. But that need a bit work and it is on my todo list...
- Martin
--- bsd.port.mk.orig2010-01-17 09:46:09.0 -0500
+++ bsd.port.mk 2010-01-17 10:36:02.0 -0500
@@ -541,6 +541,10 @@
#pattern meta-characters *, ?, [, ],
and !.
#Example: apache*-1.2* apache*-1.3.[012345]
apache-*+ssl_*
#
+# LATE_CONFLICTS - If set, this port will defer the check for conflicts
until immediately
+# before the install target, to allow conflicting ports
to be fetched and built.
+# This may expose build errors due to the presence of
conflicting ports.
+#
# Various directory definitions and variables to control them.
# You rarely need to redefine any of these except WRKSRC and NO_WRKSUBDIR.
#
@@ -4253,9 +4257,17 @@
.else
_CHROOT_SEQ=
.endif
+.if defined(LATE_CONFLICTS)
+_EARLY_CONFLICT_CHECK=
+_LATE_CONFLICT_CHECK= check-conflicts
+.else
+_EARLY_CONFLICT_CHECK= check-conflicts
+_LATE_CONFLICT_CHECK=
+.endif
+
_SANITY_SEQ= ${_CHROOT_SEQ} pre-everything check-makefile \
check-categories check-makevars
check-desktop-entries \
- check-conflicts check-depends check-deprecated \
+ ${_EARLY_CONFLICT_CHECK} check-depends
check-deprecated \
check-vulnerable buildanyway-message
options-message
_FETCH_DEP=check-sanity
_FETCH_SEQ=fetch-depends pre-fetch pre-fetch-script \
@@ -4275,8 +4287,8 @@
_BUILD_SEQ=build-message pre-build pre-build-script do-build \
post-build post-build-script
_INSTALL_DEP= build
-_INSTALL_SEQ= install-message run-depends lib-depends apply-slist pre-install
\
- pre-install-script generate-plist
check-already-installed
+_INSTALL_SEQ= install-message ${_LATE_CONFLICT_CHECK} run-depends lib-depends
\
+ apply-slist pre-install pre-install-script
generate-plist check-already-installed
_INSTALL_SUSEQ= check-umask install-mtree pre-su-install \
pre-su-install-script create-users-groups
do-install \
install-desktop-entries post-install
post-install-script \
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On Sun, 17 Jan 2010, Matthew Seaman wrote: Ion-Mihai Tetcu wrote: I'd be very happy if I could: - fetch the distfiles, even if I have a conflicting port installed - be able to use portmaster -o to switch from one port to an other one that conflicts with it. - be able to at least compile a port (eg. for testing) without having to de-install the current one. I'm all in favor of restoring the old behavior with a switch available to turn on the new one. +1 Although a big fat warning message at fetch or build phase when operating on a port with conflicts wouldn't go amiss. Agreed. A warning would give time to interrupt a big distfile fetch or build without taking that option away by default, or encouraging disabling conflict checks altogether. -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
In the last episode (Jan 17), Martin Wilke said: On Sun, 17 Jan 2010 11:44:05 +0100 Pav Lucistnik p...@freebsd.org wrote: Greg Larkin píse v so 16. 01. 2010 v 18:02 -0500: Here is the original post: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg227363.html I will agree that `portupgrade -o` is way too useful feature. I'd vote for reverting to the old behaviour. I thought portmgr might have some insight into additional reasons for making the change, such as fixing a problem with pointyhat builds, etc. At the moment, I'm neutral on the change, since it hasn't caused me any grief, but I did some research for the folks who posted the original questions. It was done because someone thought it is a good idea and submitted a PR about it. For some ports is the conflict check too late see example here. http://lists.freebsd.org/pipermail/freebsd-gecko/2009-December/000577.html I agree that we need a new pre-fetch hook in bsd.port.mk if a conflict present is. But that need a bit work and it is on my todo list... Maybe CONFLICTS could be treated like DEPENDS, with separate BUILD and RUN checks. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On 16/01/2010 6:57 π.μ., Greg Larkin wrote: 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. -- 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. - 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? Regards, Greg While I build most of my personal packages using ports-mgmt/tinderbox, this option would be very useful. I routinely run make fetch on remote machines to retrieve large distfiles, and wouldn't want the installed dependencies to interfere with that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
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. -- 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. - 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? The fetch and build targets do NOT create any conflicts. I think this solution was totally wrong and the commit should be reverted. Ruben ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
Em Sáb, 2010-01-16 às 07:00 -0500, b. f. escreveu: 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. -- Besides. when port is installed, and you try to build , the ports gets the include files from filesystem (thus getting for includes...) this makes you break , or worst... make a port that is a mix of both... that for sure is not what you want... This way (the new way) forces you to delete the package before build. it is radical, but it is safer... that is why I choose FreeBSD Sergio ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On 01/15/2010 10:57 PM, Greg Larkin wrote: 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? Regards, Greg I'd love that. The new behavior isn't a bad default, but it needs an override. Wait a minute; rewind. Isn't that what make -DDISABLE_CONFLICTS does? -- Kirk Strauser ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
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? Regards, Greg I'd love that. The new behavior isn't a bad default, but it needs an override. Wait a minute; rewind. Isn't that what make -DDISABLE_CONFLICTS does? I believe that he is talking about changing _when_ the check for conflicts is made; whereas DISABLE_CONFLICTS ignores the check, regardless of when it is made. A late check is preferable to using DISABLE_CONFLICTS, because with that knob you can shoot yourself in the foot by mistakenly installing one port on top of another. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 b. f. wrote: 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? Regards, Greg I'd love that. The new behavior isn't a bad default, but it needs an override. Wait a minute; rewind. Isn't that what make -DDISABLE_CONFLICTS does? I believe that he is talking about changing _when_ the check for conflicts is made; whereas DISABLE_CONFLICTS ignores the check, regardless of when it is made. A late check is preferable to using DISABLE_CONFLICTS, because with that knob you can shoot yourself in the foot by mistakenly installing one port on top of another. b. That's exactly what I proposed. The bsd.port.mk could be patched to support a new variable (EARLY_CONFLICT_CHECK=yes or somesuch) that shifts the check-conflict target from its old position (part of the install sequence) to its new position (fetch?). The default behavior (no mods to /etc/make.conf) would revert to the old conflict checking method. This may be something for portmgr@ to chime in on, and I'm cc'ing them now. There could be other reasons for this change that I'm unaware of. References for portmgr: http://www.freebsd.org/cgi/query-pr.cgi?pr=137855 - PR to change check-conflicts target position in bsd.port.mk http://www.mail-archive.com/freebsd-questions@freebsd.org/msg227363.html - the thread archive Regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLUgxx0sRouByUApARAqQBAJ9EYQlAe7gJpFasl3NmPlg8v4U3jQCfae1V dkSJqw520Z9DJQe0fIhGzkc= =2sdF -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On Sat, Jan 16, 2010 at 01:01:47PM -0500, b. f. wrote: 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? Regards, Greg I'd love that. The new behavior isn't a bad default, but it needs an override. Wait a minute; rewind. Isn't that what make -DDISABLE_CONFLICTS does? I believe that he is talking about changing _when_ the check for conflicts is made; whereas DISABLE_CONFLICTS ignores the check, regardless of when it is made. A late check is preferable to using DISABLE_CONFLICTS, because with that knob you can shoot yourself in the foot by mistakenly installing one port on top of another. Best: check for conflicts early, error out early if there are conflicts so one doesn't waste hours compiling something and checking/installing dependencies and so on Middling: check for conflicts late Worst: don't check for conflicts at all Yeah, sounds about right. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpIylI974DaW.pgp Description: PGP signature
Re: Dislike the way port conflicts are handled now
On 1/16/2010 1:01 PM, Chad Perrin wrote: snip Best: check for conflicts early, error out early if there are conflicts so one doesn't waste hours compiling something and checking/installing dependencies and so on Middling: check for conflicts late Worst: don't check for conflicts at all Yeah, sounds about right. That does nothing for conflict resolution, though. That's a big concern for me because in the past, only one distribution of Linux (not having used any of the BSD's before, cannot comment on them except for what I'm seeing in this discussion) that I've used seems to handle not only package dependency with ease and grace, but also conflict resolution (in the sense that the only time I've had an issue with conflicts was when an updated package wasn't available or an older required package was discontinued). I like the fact that FreeBSD checks for conflicts early, but erroring out without anything really useful is a negative for me. Instead of erroring out, why not initiate some sort of conflict resolution (e.g. remove and or update an old port) when the conflict is first detected? Yes, it may very well mean increased time to install a package, especially if compiling from source, but I find that a more elegant solution then just erroring out and requiring yet another manual step. Of course there could be an option to opt-out of this sort of behavior too, for those who like the extra steps. -- PIT signature.asc Description: OpenPGP digital signature
Re: Dislike the way port conflicts are handled now
On Sat, 16 Jan 2010 13:18:15 -0600 Programmer In Training p...@joseph-a-nagy-jr.us articulated: That does nothing for conflict resolution, though. That's a big concern for me because in the past, only one distribution of Linux (not having used any of the BSD's before, cannot comment on them except for what I'm seeing in this discussion) that I've used seems to handle not only package dependency with ease and grace, but also conflict resolution (in the sense that the only time I've had an issue with conflicts was when an updated package wasn't available or an older required package was discontinued). I like the fact that FreeBSD checks for conflicts early, but erroring out without anything really useful is a negative for me. Instead of erroring out, why not initiate some sort of conflict resolution (e.g. remove and or update an old port) when the conflict is first detected? Yes, it may very well mean increased time to install a package, especially if compiling from source, but I find that a more elegant solution then just erroring out and requiring yet another manual step. Of course there could be an option to opt-out of this sort of behavior too, for those who like the extra steps. If I remember correctly, 'portmanager -y' removed conflicting ports prior to installing a new or updated port. -- Jerry ges...@yahoo.com |=== |=== |=== |=== | Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. Oscar Wilde ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
Greg Larkin píše v so 16. 01. 2010 v 13:58 -0500: That's exactly what I proposed. The bsd.port.mk could be patched to support a new variable (EARLY_CONFLICT_CHECK=yes or somesuch) that shifts the check-conflict target from its old position (part of the install sequence) to its new position (fetch?). The default behavior (no mods to /etc/make.conf) would revert to the old conflict checking method. This may be something for portmgr@ to chime in on, and I'm cc'ing them now. There could be other reasons for this change that I'm unaware of. What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling... -- Pav Lucistnik p...@oook.cz p...@freebsd.org It's the classic Microsoft security-bulletin formula: The vulnerability is important (never dangerous); you have nothing to fear and no reason to regret trusting us; we have no intention of apologizing for it or even explaining it adequately; now go get your patch, shut up, and be grateful nothing bad has happened. -- The Register signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: Dislike the way port conflicts are handled now
On Sat, 16 Jan 2010 13:01:47 -0500 b. f. bf1...@googlemail.com wrote: Wait a minute; rewind. Isn't that what make -DDISABLE_CONFLICTS does? I believe that he is talking about changing _when_ the check for conflicts is made; whereas DISABLE_CONFLICTS ignores the check, regardless of when it is made. A late check is preferable to using DISABLE_CONFLICTS, because with that knob you can shoot yourself in the foot by mistakenly installing one port on top of another. I think the point is you can make -DDISABLE_CONFLICTS using targets other than install ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pav Lucistnik wrote: Greg Larkin píše v so 16. 01. 2010 v 13:58 -0500: That's exactly what I proposed. The bsd.port.mk could be patched to support a new variable (EARLY_CONFLICT_CHECK=yes or somesuch) that shifts the check-conflict target from its old position (part of the install sequence) to its new position (fetch?). The default behavior (no mods to /etc/make.conf) would revert to the old conflict checking method. This may be something for portmgr@ to chime in on, and I'm cc'ing them now. There could be other reasons for this change that I'm unaware of. What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling... Hi Pav, I'm not the one who posted the original message to the list, but I'm participating in the conversation with some of the folks who expressed a preference for checking conflicts later in the build process. Here is the original post: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg227363.html I thought portmgr might have some insight into additional reasons for making the change, such as fixing a problem with pointyhat builds, etc. At the moment, I'm neutral on the change, since it hasn't caused me any grief, but I did some research for the folks who posted the original questions. What do you think of adding an entry to UPDATING to note a change like this in the build process? For instance, I wasn't aware of the LOCALBASE=/nonexistent idea that you mentioned, so the entry could include that and some other tips. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLUkWE0sRouByUApARApVWAKCmof3lBaN+R58UkPm82KjNvt9RCACeMExc uQCKc9mU4ou9qJ95fz6sv5Y= =Eq2R -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On 1/16/10, Pav Lucistnik p...@freebsd.org wrote: Greg Larkin píše v so 16. 01. 2010 v 13:58 -0500: That's exactly what I proposed. The bsd.port.mk could be patched to support a new variable (EARLY_CONFLICT_CHECK=yes or somesuch) that shifts the check-conflict target from its old position (part of the install sequence) to its new position (fetch?). The default behavior (no mods to /etc/make.conf) would revert to the old conflict checking method. This may be something for portmgr@ to chime in on, and I'm cc'ing them now. There could be other reasons for this change that I'm unaware of. What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling... Some people want to be able to fetch and build ports that conflict with installed ports, without going to the trouble of (1) re-installing all of the build dependencies in an alternate LOCALBASE; or (2) first de-installing, and then afterwards reinstalling the conflicting ports. And they want to do this without disabling the conflict check, so that they don't mistakenly corrupt an installed port. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On Sat, 16 Jan 2010 21:26:28 +0100 Pav Lucistnik p...@freebsd.org wrote: Greg Larkin píše v so 16. 01. 2010 v 13:58 -0500: That's exactly what I proposed. The bsd.port.mk could be patched to support a new variable (EARLY_CONFLICT_CHECK=yes or somesuch) that shifts the check-conflict target from its old position (part of the install sequence) to its new position (fetch?). The default behavior (no mods to /etc/make.conf) would revert to the old conflict checking method. This may be something for portmgr@ to chime in on, and I'm cc'ing them now. There could be other reasons for this change that I'm unaware of. What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling... I'd be very happy if I could: - fetch the distfiles, even if I have a conflicting port installed - be able to use portmaster -o to switch from one port to an other one that conflicts with it. - be able to at least compile a port (eg. for testing) without having to de-install the current one. I'm all in favor of restoring the old behavior with a switch available to turn on the new one. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Dislike the way port conflicts are handled now
On 01/16/2010 02:26 PM, Pav Lucistnik wrote: What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling.. Pav, I'm the OP, and described the problem in the first post. To recap, though, say I want to upgrade from the databases/mysql50-client port to databases/mysql51-client. Without taking extra steps such as using -DDISABLE_CONFLICTS or removing the CONFLICTS definition from the Makefile, I can't even start downloading the distfiles (using make fetch) until I pkg_delete the old version. With the old system, I could do everything up through building the new port so that the time between running pkg_delete and make reinstall is minimized. -- Kirk Strauser ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
On Sat, 16 Jan 2010 18:08:30 -0600 Kirk Strauser k...@strauser.com wrote: On 01/16/2010 02:26 PM, Pav Lucistnik wrote: What is the particular scenario that the new conflicts handling broke for you? Often you really want to ignore locally installed packages and then it's better to override LOCALBASE to /nonex or something similar, instead of disabling conflict handling.. Pav, I'm the OP, and described the problem in the first post. To recap, though, say I want to upgrade from the databases/mysql50-client port to databases/mysql51-client. Without taking extra steps such as using -DDISABLE_CONFLICTS or removing the CONFLICTS definition from the Makefile, I can't even start downloading the distfiles (using make fetch) until I pkg_delete the old version. With the old system, I could do everything up through building the new port so that the time between running pkg_delete and make reinstall is minimized. Is it so hard to type make -DDISABLE_CONFLICTS fetch to, fetch and make -DDISABLE_CONFLICTS to build - given that this is something that's rarely needed. When I first read this it sounded bad, but the more I think about it the more I think the change is sensible. If it bothers you that much why don't you just alias make -DDISABLE_CONFLICTS to make-anyway. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Dislike the way port conflicts are handled now
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. -- Kirk Strauser ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
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. -- 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. - Craig ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dislike the way port conflicts are handled now
-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. -- 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. - 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? Regards, Greg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktRRz8ACgkQ0sRouByUApA35ACfY9NU8NBKarCm6eTFRLt1y/Nf ar8AoIxF68LgUZBuATfHLRyfaAZ9SOtw =kG5z -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
