binary patches?

Beech Rintoul beech at
Wed Mar 14 23:55:44 UTC 2007

On Wednesday 14 March 2007 15:00, Gary Kline said:
> On Wed, Mar 14, 2007 at 05:07:43PM +0100, Gabor Kovesdan wrote:
> > Gary Kline schrieb:
> > >	Regarding most (or many) of the port changes--say, upgrading
> > >	foo-2.1.9_5 to foo-2.1.9_6, if  the upgrade could be done by
> > >	downloading a binary diff file, could the resulting
> > >	/usr/local/bin/foo-2.1.9_6 be achieved by downloading a
> > >	relatively small binary patch?  Seems to me that smaller scale
> > >	upgrades could be done this way in preference to re-compiling
> > >	ports or downloading entire pacakes.  --Same would go for any
> > >	dependencies.
> > >
> > >	Why is this a bad idea!
> > >
> > >	gary
> >
> > The final form of actual binaries depend on a lot of things, e.g.
> > which version of dependency you compiled with, which CFLAGS you
> > have used, what options the port you built it. Some of these
> > applies to packages as well, that's why I prefer ports over
> > packages at all. E.g. let's see lang/php5. It does not have the
> > apache module enabled by default. If it were, then the problem
> > comes up with Apache versions. IIRC, 2.2 is the default now, but
> > what if you use 2.0? How would you install php for your apache
> > version from package? The situtation has been already pretty
> > complicated with packages if you have higher needs for fine
> > tuning, but you can use them if you don't have special needs.
> > Binary diffs would be so complicated that I think this way we
> > could really not follow.
> >
> > If you need simplicity at all, use portupgrade with packages. It
> > has an option (don't remember which one) you can use to make it
> > fetch packages instead of building from source. Nowadays, this
> > network traffic should not be a real problem, I think.
> 	You've brought up a lot of things I didn't consider; this was
> 	part of the reason for my post.  It seems to me that there would
> 	need to be some simple ground rules from the binary patches I'm
> 	got in mind.  The *default* CFLAGS in the port would match those
> 	in the patch is one place to start.
> 	Obviously, this could get way out of hand very quickly.  Two of
> 	my slowest servers (one 400MHz, 192M RAM) were rebuilding parts
> 	of the KDE suite; the new kdelib-3.5.6 [??] just finished and I
> 	already scp'd it over to my more beefy platform.  Once I've got
> 	all my servers up to date, it may not be that hard to keep them
> 	current.  You're right that bandwidth isn't a problem--um, in
> 	most places {{ clearing my throat! }}.  Bandwidth isn't the main
> 	issue.  It's time.
> 	cheers!
> 	gary
> > Regards,
> > Gabor

This issue comes up about every six months. If you google the mailing 
list you will find extensive discussion about why binary upgrades are 
a bad idea. If you want to upgrade using packages only 
use 'portupgrade -PP'. Bear in mind it takes the package build 
cluster a couple of weeks to catch up. For security reasons we 
(maintainers) don't build packages and building binaries for every 
possible configuration would place an extreme load on the build 
cluster (not to mention the space required to host them all).


Beech Rintoul - Port Maintainer - beech at
/"\   ASCII Ribbon Campaign  | FreeBSD Since 4.x
\ / - NO HTML/RTF in e-mail   |
 X  - NO Word docs in e-mail | Latest Release:
/ \  -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-questions mailing list