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

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

 



Mark Haney wrote:
Alan Evans wrote:

No, I don't understandably say it's too bleeding edge.  I didn't say
that at all.  But, I don't mind testing packages.
Fine. So packages in rawhide should be moved continuously into updates
as each is found worthy of general use? But how? If by the time the
kinks are worked out, the new package requires libfoo.9, then libfoo.9
will be updated to replace the libfoo.7 that's in updates. Now
everything that required libfoo.7 also has to be moved into updates.
But what if the kinks haven't yet been worked out of those programs?
And even if they were, one of those programs may now require
libbar.65, which forces that to replace libbar.56. This doesn't have
to go very far before it's not considerably different than making a
formal release. We've gained nothing, and the whole system is probably
much less stable.

See, that's my point.  There is no difference between 'yum update' and
'emerge -upD world' when you think about it.  When you update Fedora
between release cycles, you're technically upgrading the system to a new
version.  Whether it be a major or minor version is irrelevant for the
point of this argument.  If the update to a package is not just a
security update, but an /upgrade/ to a newer version, the OS is
upgraded.  And let's not get into semantics here.

No, this isn't semantics, there are four things involved here, not two:
- the OS is really just the kernel. In general you can update that
  without breaking everything. But if ACPI or similar changes, then
  some apps or scripts may fail.
- applications. Changes and upgrades to one application can be made
  freely, since they don't impact other things. Unless, of course, they
  need a change in...
- libraries. Changing a library means you have to control every application
  which uses the library. Since that may include user applications, non-
  Fedora applications, commercial databases, etc, that means that there is
  a very high chance of breaking things if a library is upgraded (as opposed
  to bug fixes, and other changes which don't change the API or behavior).
- the distribution. The things which make one Linux different from another,
  including package management, graphics, window manager, location of
  system files, graphics, system features like udev, SElinux, boot scripts
  and files, compilers and interpreters like C, perl, and python, and other
  things which have to all stay compatible with one another.

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?
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.

Compiling solves little, unless you mean compiling every application on the system each time you change a library in a non-trivial way. And of course if you change the compiler itself, there is no promise that multiple things don't break. Just look through the rawhide change listing and search for gcc, perl, and python, with notes like "fixed issue with gcc x.x.x" indicating that the application couldn't just be recompiled with the new compiler and library, source code changes were needed.

I just don't see how that can work in a general-purpose binary
distribution. Perhaps you have some ideas about how it can be
practically done that you haven't shared?


See above.  Honestly, I've not delved deep into a feasibility study of
this, but I fail to see a rational explanation for why it /can't/ be
done.  It makes no difference to me if it /should/ or /will/ be done. I
voiced my opinion and defended it fairly well (I think).  If the Fedora
team never goes that route, it's no skin off my nose.  I will continue
to use it like I have been since FC1.  I like it.  It's never been a
pain to use (FF & NM not withstanding) and unless that changes for me
I'm going to stick with it.

Hopefully the above is deep enough delving to assure you that new releases from time to time are actually the least painful way to go.

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux