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@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > > To unsubscribe, send any mail to
> > > "[EMAIL PROTECTED]"
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Gary Kline [EMAIL PROTECTED] www.thought.org Public Service Unix
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
