Date: Wed, 1 Dec 2010 08:41:49 -0600 From: Ade Lovett <ade@FreeBSD.org> To: M K <ibdmbk@yahoo.com> Cc: freebsd-ports Ports <freebsd-ports@freebsd.org> Subject: Re: Port updating instructions and portmaster -a Message-ID: <0C9CF395-EFA7-464A-8EC5-9B2EF549AACD@FreeBSD.org> In-Reply-To: <137508.95194.qm@web45304.mail.sp1.yahoo.com> References: <137508.95194.qm@web45304.mail.sp1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 01, 2010, at 00:53 , M K wrote:
> [major snippage to get to the point]
>=20
> Given the time, the users could pick and choose which ports to update.
Herein lies the fundamental problem with upgrading ports, particularly =
those which affect a large number of other ports, of which I, amongst =
others, have a certain degree of understanding.
When it comes to testing such updates, they are done in a "clean room" =
environment, whether it is a local tinderbox, or a full -exp package =
build run. Ports, and those that depend upon them, are built in natural =
order (ie: if A depends on B which depends on C, then the build order is =
C->B->A)
The ports tree contains bugs, naturally. Implicit dependencies where =
explicit ones are needed are the most obvious. "Oh, cool, configure =
script found <libfoo> so I shall link against it even though you didn't =
ask" is a little less common, but prevalent enough. And so the list =
continues.
As such, the deeper down inside the chain a port is that has been =
updated, so the number of combinations and edge cases increases =
exponentially to the point where given that cpu time (compiling) is =
vastly cheaper than human time (answering "A didn't rebuild because I =
had Q, W, but not X"), it is simply easier to pull out the compilation =
sledgehammer and say "rebuild everything depending on updated port =
<bar>" or, in extreme cases, "rebuild _everything_" (I don't think this =
has happened yet, but most gettext upgrades, fortunately relatively few =
and far between, are pretty close contenders for this).
One should also note that whilst the capability exists, via =
${LOCALBASE}/lib/compat/pkg, for old shared libraries to be kept, if you =
have ports Q and R, both depending on port V, and via the =
pick-and-choose method you choose to update V and one of Q or R, then =
Really Bad Things [tm] will start to happen.
In an isolated case of >one< end-user picking-and-choosing, then your =
approach would be viable with the caveats above. Regretfully, we have =
many tens of thousands of end-users, with differing environments, and =
thus out of pure simplicity and saving of overall time, =
portmaster/portupgrade instructions occasionally come down via UPDATING =
in the shape of a really BIG hammer.
If someone[tm] could _provably_solve_ this upgrading problem, I'll make =
you famous (and take a 2% cut, I'm not greedy)
-aDe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C9CF395-EFA7-464A-8EC5-9B2EF549AACD>