binary patches?

[Gary Kline]

On Thu, Mar 15, 2007 at 02:57:14AM +0100, Danny Pansters wrote:
> On Thursday 15 March 2007 00:00, Gary Kline wrote:
> > 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!
> 
> I don't think it's a bad idea at all, but impractical
> 

	After this discussion, I can see the myriad facets;
	doable? yes, practical: no, sir.  To implement the
	kind of blue-sky thing I had in mind is what's known
	as "the plausable impossible."  Like a talking mouse
	who owns a dog and talks.    


> > > >
> > > >	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.
> 
> Yes, seperate binpatches for every port option or build setting. And for any 
> differently configured dependency! And those would have to be all checksummed 
> also. Preferably from a seperate reliable source. So it quickly gets much 
> much bigger and complicated than a source-only approach. Which is complicated 
> enough as it stands :)
> 
> > > 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.
> 
> But you only had an example with one single binary. Not many useful apps 
> installs one single binary. And then there's a multitude of libs (which of 
> course depend on other libs)
> 
> > 	Obviously, this could get way out of hand very quickly.  Two of
> 
> Yes, after two iterations or so. IOW: instantly.
> 

	Yup.  :-)



> > 	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!
> 
> Also, it frequently happens that when upgrading a large project (say Gnome) 
> you pretty much have to remove the old-install the new anyway.


	Gawk!  I'm going to have *nightmares* thinkng about Gnome!
	I'm overdue for buying a FBSD CD-ROM set when that happens....

> 
> As others said as well, it's a nice idea if you have unlimited manpower, but 
> practically speaking it's a maintenance nightmare much more than a source 
> approach is.
> 

	Well said.  And until everybody is in the upper 0.5 percentile
	andor somebody donates $millions andor lots more of us get back
	into the hacking side of the Project, we'll just make do.

	I've appreciated all the (rational) input!

	gary



> 
> Cheers,
> 
> Dan
> 
> > 	gary
> >
> > > Regards,
> > > Gabor
> > > _______________________________________________
> > > freebsd-questions at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > > To unsubscribe, send any mail to
> > > "freebsd-questions-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
  Gary Kline  kline at thought.org   www.thought.org  Public Service Unix