From owner-freebsd-ports Thu Feb 8 17:45:36 2001 Delivered-To: freebsd-ports@freebsd.org Received: from blizzard.sabbo.net (pop3.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 9099D37B65D; Thu, 8 Feb 2001 17:45:15 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f191j8608629; Fri, 9 Feb 2001 03:45:09 +0200 Received: (from max@localhost) by vic.sabbo.net (8.11.2/8.11.2) id f191j9513959; Fri, 9 Feb 2001 03:45:09 +0200 (EET) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200102090145.f191j9513959@vic.sabbo.net> Subject: Re: Ports updating... Good ways? To: bmah@FreeBSD.ORG Date: Fri, 9 Feb 2001 03:45:04 +0200 (EET) Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), kraemer@u.washington.edu (Brian Kraemer), freebsd-ports@FreeBSD.ORG In-Reply-To: <200102082229.f18MTC806430@bmah-freebsd-0.cisco.com> from "Bruce A. Mah" at Feb 08, 2001 02:29:12 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Let's say I install the "gtkwooba" port which depends on gtk, > > libtools, glib and libwooba. Then I come back over a year later and > > do a "make update" in gtkwooba. It's pretty much a surety that just > > about everything it depends on has been updated, so I have to upgrade > > gtk, libtools, glib and libwooba too. > > I'm not sure about that. You should only have to upgrade the > dependencies listed in the Makefile for gtkwooba that aren't still > satisfied. For example, even if libtool has been upgraded, the > executable /path/to/libtool still exists, and so "make install" for > gtkwooba isn't going to try to update that. I presume that's still the > correct behavior. It's questionable point. The real life is often more messy and new version of a port may need really up-to-date versions of its dependencies. Good example is my addition of --build= stub into libtool. While this change is undetectable from the point of view of package dependency mechanism (i.e. no files were added or removed), change in functionality would prevent ports that use that feature from building correctly if older version is installed (anything below 1.3.4_1). There are several more complicated cases of this problem as well. Consider the following sequence: 1. port A-1.0 created; 2. port B-1.0 created and depends on A; 3. new version 1.1 of port B released that relies upon feature that was present but no enabled in the current A-1.0 port; 4. maintainer revises port A-1.0 to enable requred for 1.1 version of the port B feature and bumps PORTREVISION to indicate that upgrade necessary; 5. port B updated to the new version 1.1. The similar situation would be in the case when some backward but not forward compatible changes were made in the software without shared library version bump (common situation in the GTK/Gnome word). Therefore the only safe method is to assume that a port needs most up-to-date versions of its dependencies. This, however, lead us to the necessity to update not only dependencies, but all the ports which depend on that dependencies. Take a look at the following simple graph: A --> B <-- C ^ | D The graph shows that packages A, C and D depend on package B. Then when we are trying to upgrade C and discovered that new version of B is available we have to update not only B and C, but all packages A, B, C, D, because new version of package C may need new version of package B, while new version of package B may be incompatible with already installed A and D, so we need to update them as well. This of course is a very simple case, in the real world graph would be much more complicated, so update of one package could trigger update of the whole set of installed packages. *sigh* Well, I have to emphasize that I said the above not to discourage you or anybody else, but to highlight some of the most important, in my own opinion of couse, problems with authomatic updating of ports/packages. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message