Date: Fri, 9 Feb 2001 03:45:04 +0200 (EET) From: Maxim Sobolev <sobomax@FreeBSD.ORG> To: bmah@FreeBSD.ORG Cc: jkh@winston.osd.bsdi.com (Jordan Hubbard), kraemer@u.washington.edu (Brian Kraemer), freebsd-ports@FreeBSD.ORG Subject: Re: Ports updating... Good ways? Message-ID: <200102090145.f191j9513959@vic.sabbo.net> In-Reply-To: <200102082229.f18MTC806430@bmah-freebsd-0.cisco.com> from "Bruce A. Mah" at Feb 08, 2001 02:29:12 PM
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102090145.f191j9513959>