Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Feb 2001 18:18:21 -0800
From:      "Bruce A. Mah" <bmah@FreeBSD.ORG>
To:        Maxim Sobolev <sobomax@FreeBSD.ORG>
Cc:        bmah@FreeBSD.ORG, 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:  <200102090218.f192ILh13295@bmah-freebsd-0.cisco.com>
In-Reply-To: <200102090145.f191j9513959@vic.sabbo.net> 
References:  <200102090145.f191j9513959@vic.sabbo.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_-53236343P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Maxim Sobolev wrote:

> > > 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).

Hi Max--

Good points.

I'd say that in this situation we're no *worse* off than we are
currently.  A situation like this breaks installs of new ports also, not
just updates.  How is the user supposed to know that she has to go 
upgrade libtool if for all she knows she is just going to install 
libwooba?

[snip]

> 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:

This is a situation that our current dependency infrastructure is 
completely inadequate for.  I don't know if I just stepped on people's 
toes or said something mind-numbingly obvious or both.  Apologies if 
any of those are true.

I interpret what you wrote as saying that "make install" for a port is
potentially broken.  This is shocking to me.

> 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.

Point well taken.

By now you've probably seen the patch for bsd.port.mk I posted.  I 
believe that it's consistent with the current functionality of the rest 
of bsd.port.mk (and apparently broken in the same ways).  Perhaps its 
main contribution to the body of knowledge on this problem is that it 
works within the confines of bsd.port.mk, and has only a couple of 
grotesque hacks where it has to grovel into the package database.

I don't have any emotional attachment to what I posted, and I probably
don't have any time to work on this further, so if if someone wants to
pick it up and run with it, or if it dies from apathy, that's fine by
me.  I actually did use some test cases to update some ports that needed
updating on one of my systems, so it wasn't a complete waste of time for
me.  :-)

Well actually I lied.  I do have one attachment to my solution...I want
people to stop doing "pkg_version -c | sh" (how many times can I write
that today?) and this seemed like a pretty good alternative.

Cheers,

Bruce.



--==_Exmh_-53236343P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE6g1Nt2MoxcVugUsMRAuy0AKCQ5u44QCt+XlmFF1uLqv2vg5EepACfcR1k
6Pcz+MdkqW3FgqKtL9TALnQ=
=PP4K
-----END PGP SIGNATURE-----

--==_Exmh_-53236343P--


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?200102090218.f192ILh13295>