Re: New rpm version about to hit rawhide

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

 



Kevin Kofler wrote:
> Andy Green <andy <at> warmcat.com> writes:
>>>> Of the two issues, surely memory use is the worst?
> 
> Surely correctness is more important!

It is very important, but so is being able to upgrade Fedora at all on a
given box.  In my usage case I am visiting three different relatives and
friends houses now and then with limited time available to do an
upgrade, on hardware that is past its use-by date.  If the cost of
getting the docs straight means actually upgrading it is out of scope
that isn't good (besides rm -rf /usr/share/doc is the first move if disk
space runs low on these old clunkers).

>> But if the price in memory for solving a multilib issue has to be paid
>> for even when a single arch is all there is, that would be more painful
>> since already struggling low memory single-arch boxes have to pay it for
>> no benefit to them.
> 
> There is a benefit. This bug doesn't only affect multilib. Another common case 
> where it triggers is failed %postun scriptlets. When you then 
> rpm -e --noscripts the old version, suddenly some files are gone.

Well clearly such a bug should be fixed, no doubt about it.  But if the
implementation of the fix is very expensive in memory it can mean the
fix broke the ability of some people to upgrade.  So then you have to
trade off the apples of the fix with the oranges of the breakage.

(Assuming the additional memory use actually represents a bad enough
problem for these low end machines, maybe it's just a MB or two in which
case it doesn't make much odds.)

> I've already given up on Anaconda on that laptop. I just used apt-rpm to 
> upgrade from FC5 to FC6 (which has the advantage of being able to swap out 
> whereas Anaconda tends to simply crash when it runs out of memory) and I'm 
> planning to the the same for FC6->F7. (It's still running FC6 right now.) The 
> FC2->FC5 Anaconda upgrade had to be restarted a couple of times due to Anaconda 
> just locking up from lack of memory. Luckily, it did that when computing the 

Yes F7 Anaconda did a smart thing after the partitioning was defined,
told me it was going to do the swap partition right away because it
could see I didn't have a lot of memory.

Still I was told some years ago that Anaconda had magic meta-knowledge
about packages that does not live in the specfiles and that this could
lead to diverging behaviour on dist upgrades.  And if I am encouraging
someone to install Fedora themselves on a low end box, I don't want to
have to explain that they have to go around Anaconda.

> upgrades from the next ISO (I did a HD install with CD ISOs), not in the middle 
> of a transaction. So now I'm unwilling to let Anaconda anywhere near that 
> machine, it doesn't have enough RAM. Oh, and to compensate, apt-rpm memory use 
> is going to improve a lot with SQLite metadata support which is already in the 
> latest development version, so I'm not worried.

Just saying that "dramatic" increases in memory usage in rpm can destroy
the possibility for existing users on existing Fedora machines to
upgrade in a reasonable period or possibly at all.  Maybe further work
in rpm will win all the memory back and more.

-Andy

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux