[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Feature Proposal: Rolling Updates (was Re: WHY I WANT TO STOP USING FEDORA!!!)



Alan Evans wrote:
> On Wed, Feb 11, 2009 at 6:08 AM, Mark Haney wrote:
>> Alan Evans wrote:
>>> As I understand it, Gentoo doesn't suffer this because each user is
>>> compiling their own package sets. Updating libfoo doesn't require
>>> recursively redownloading every package that requires it because the
>>> user already has the source to those programs. He just needs to
>>> recompile them.
>> Explain to me how doing an update in Fedora requires the same method?
> 
> I'm not sure I understood this question.
> 
>> If I update package 'appfoo' that requires 'libfoo' there's no
>> difference between downloading and reinstalling the libfoo RPM along
>> with the new version of 'appfoo' than it is recompiling libfoo in
>> gentoo.  I /still/ have to download the source code to recompile it,
>> unless I just happen to have that source (and it's not be updated)
>> sitting in my portage cache.  The idea is the same, just a slightly
>> different mechanism.  And with delta packages, this would be a cinch I
>> would think.
> 
> But what about appbar that also requires libfoo? Unless I'm
> misunderstanding how Gentoo works (which is possible), you don't need
> to redownload appbar because libfoo was updated. You only need to
> recompile appbar after updating libfoo.

Not exactly.  If libfoo gets updated you must rebuild appfoo against the
new libraries.  And, unless you have the source tarball cached on the
system (which portage does cache but like cleaning up yum doesn't keep
everything) you will need to download the source again and recompile.

> 
> This means that appbar on your machine is different than appbar on my
> machine because each is compiled against a different set of libraries.
> This is not a big deal since each machine is internally consistent.

No, it's not different than on yours unless you've not updated to
'libfoo'.  There /is/ one caveat though.  It's entirely likely your
binary will be different from mine in Gentoo.  Since Gentoo compiles
everything from source (there are binary packages available as well) you
can control all your compile time options.  I streamline mine for KDE
and floating point operations, but yours might be for GNOME.  Etc.  In
that case, each Gentoo system is different unless both systems have the
exact same compile options.

> But with a binary distro, the repository must be internally
> consistent. This means that if a single package (even one I don't have
> on my machine) requires a new libfoo then I have to update every
> package on my machine that touches, even indirectly, libfoo, because
> libfoo was updated in the repository, which caused apps that I do have
> installed to be updated just to be compatible with the updated libfoo.

Yes, and?  How's that any different from the way Gentoo does it? I still
have to update all my packages that use that library same as you do.
It's just a different way to skin that cat.

> 
> -Alan
> 
> (As I said, I might be wrong about how Gentoo works. But if you don't
> keep source for installed packages handy for recompilation when libs
> get updated then I wonder what is the point of Gentoo at all, unless
> it's just the warm fuzzies of knowing that your binaries are compiled
> against your particular arch.)
> 

I keep binary packages of stuff I update just in case. But I like Gentoo
because I don't need my binaries built with GNOME support since I'm KDE
only.  I also only build for one media player, no LDAP support, etc.  It
cuts down on the clutter and makes for much smaller binaries and the
number of libraries I have to manage.


-- 
Frustra laborant quotquot se calculationibus fatigant pro inventione
quadraturae circuli

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]