Re: Overly restrictive checks in the make process
On Sat, Jul 21, 2007 at 06:20:53AM -0400, Bill Moran wrote: Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? Yes, use the NO_IGNORE variable (which just passed its tenth birthday) to override IGNORE checks you disagree with. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Kris Kennaway [EMAIL PROTECTED]: On Sat, Jul 21, 2007 at 06:20:53AM -0400, Bill Moran wrote: Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? Yes, use the NO_IGNORE variable (which just passed its tenth birthday) to override IGNORE checks you disagree with. Huh ... here I am bitching and that's been there all along ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Overly restrictive checks in the make process
[EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive === Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies === postgresql-server-8.2.4_1 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Why? Is there a legitimate reason why the fetch process refuses to download this? I know I've got an older version installed, but why is it preventing me from downloading a newer one? Seems like the IGNORE= check is either being checked too aggressively or that the logic is less sophisticated than it should be. Does anyone know of a reason why this couldn't be changed to allow fetching of conflicting ports distfiles? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
Bill Moran wrote: [EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive === Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies === postgresql-server-8.2.4_1 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Why? Is there a legitimate reason why the fetch process refuses to download this? I know I've got an older version installed, but why is it preventing me from downloading a newer one? Seems like the IGNORE= check is either being checked too aggressively or that the logic is less sophisticated than it should be. Does anyone know of a reason why this couldn't be changed to allow fetching of conflicting ports distfiles? Sounds like a +CONFLICTS type of issue (the MySQL client and server files for instance install some libs in the same spot, so they conflict IIRC). -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Garrett Cooper [EMAIL PROTECTED]:
Bill Moran wrote:
[EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make
fetch-recursive
=== Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies
=== postgresql-server-8.2.4_1 cannot install: the port wants
postgresql82-client but you have postgresql81-client installed.
*** Error code 1
Why? Is there a legitimate reason why the fetch process refuses to
download this? I know I've got an older version installed, but why
is it preventing me from downloading a newer one? Seems like the
IGNORE= check is either being checked too aggressively or that the
logic is less sophisticated than it should be.
Does anyone know of a reason why this couldn't be changed to allow
fetching of conflicting ports distfiles?
Sounds like a +CONFLICTS type of issue (the MySQL client and server
files for instance install some libs in the same spot, so they conflict
IIRC).
Actually, it's IGNORE, as I stated earlier:
.if defined(WANT_PGSQL_VER) defined(_PGSQL_VER) ${WANT_PGSQL_VER} !=
${_PGSQL_VER}
IGNORE= cannot install: the port wants
postgresql${WANT_PGSQL_VER}-client but you have postgresql${_PGSQL_VER}-client
installed
.endif
and the same behaviour is used all through the ports collection ...
php4/php5 is another example.
But that's nit-picky details. My question is _why_ is that check run
for fetch? I can see no reason why it's taboo to fetch multiple port
versions, and in the case of an upgrade where time is short, having
the package fetched prior to the outage window can be a huge time-
saver.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 09:14:32AM -0700, Garrett Cooper wrote: Sounds like a +CONFLICTS type of issue (the MySQL client and server files for instance install some libs in the same spot, so they conflict IIRC). Not as far as I know. make install in databases/mysql50-server will cause databases/mysql50-client to get installed. Verification of the results: (09:32:40 [EMAIL PROTECTED]) ~ $ pkg_info | grep ^mysql mysql-client-5.0.41 Multithreaded SQL database (client) mysql-server-5.0.41 Multithreaded SQL database (server) I think what Bill was asking about, though, was why the IGNORE in the port is getting hit for make fetch. For make or make install or other such things, it seems valid, but for fetching distdata it seems erroneous. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Jeremy Chadwick [EMAIL PROTECTED]: On Fri, Jul 20, 2007 at 09:14:32AM -0700, Garrett Cooper wrote: Sounds like a +CONFLICTS type of issue (the MySQL client and server files for instance install some libs in the same spot, so they conflict IIRC). Not as far as I know. make install in databases/mysql50-server will cause databases/mysql50-client to get installed. Verification of the results: (09:32:40 [EMAIL PROTECTED]) ~ $ pkg_info | grep ^mysql mysql-client-5.0.41 Multithreaded SQL database (client) mysql-server-5.0.41 Multithreaded SQL database (server) I think what Bill was asking about, though, was why the IGNORE in the port is getting hit for make fetch. For make or make install or other such things, it seems valid, but for fetching distdata it seems erroneous. That is correct. I apologize if I was unclear earlier. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: Why? Is there a legitimate reason why the fetch process refuses to download this? The intention of the logic is to warn a user, as soon as possible, that they are spending time on something that will wind up being IGNOREd if it is installed. There is no logic there to try to figure out later version of port; it simply looks for is IGNORE set? Since some downloads take a long time, this does not seem too unreasonable to me. If we moved the check later, the process of trying to install a port that would be IGNOREd would be: spend time fetching and checksumming it, and only then tell the user that they had wasted their time. I think the best we could do is add something analagous to how DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only if demanded, but turn it off by default. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to [EMAIL PROTECTED] (Mark Linimon): On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: Why? Is there a legitimate reason why the fetch process refuses to download this? The intention of the logic is to warn a user, as soon as possible, that they are spending time on something that will wind up being IGNOREd if it is installed. There is no logic there to try to figure out later version of port; it simply looks for is IGNORE set? Since some downloads take a long time, this does not seem too unreasonable to me. If we moved the check later, the process of trying to install a port that would be IGNOREd would be: spend time fetching and checksumming it, and only then tell the user that they had wasted their time. I suspected there was some reasoning along that line. I think the best we could do is add something analagous to how DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only if demanded, but turn it off by default. That would be less annoying than having to constantly hack files in /usr/ports/Mk ... :) Even better would be for make to realize that it's only doing the fetching, and do it anyway. I don't know if this is possible, though. Sooner or later, the person running the system is going to pull out the foot-gun (you can only protect them so much) and waiting for a download that can't install is a comparatively small bullet ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
