Bill Davidsen wrote: > Mark Haney wrote: >> Bill Davidsen wrote: >>> 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. >> >> Really? Oh no, I thought we covered that several threads up. The >> kernel is understood. No one is questioning that and for the most part >> I was NOT talking about the kernel. I hate repeating myself. >> >>> - 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). >> >> Again, I am well aware of libraries. But Fedora handles library updates >> just fine 'between releases' so what's your point exactly? To me >> updates that are done to a system say, between F9 and F10 are nothing >> more than rolling updates. Is this not so from any standpoint? And if >> not, explain to me how it's not? During ANY update you do on your F10 >> system libraries are affected. So I see no difference doing continuous >> updates this way and the current method Fedora uses with updates to a >> 'version' between releases. >> > Maybe someone else can explain this to you, you obviously read what I > wrote (maybe) and didn't have a clue of the implications. If you update > just *one* application which requires an upgrade (which is not totally > 100% compatible with the previous version) of a library, you break every > application which needed the old library as it was. And the only way to > fix that is to upgrade every application which uses the library, and > every script which might break using the new versions of the > applications... and stuff you wrote, or compiled, of downloaded may also > break. That's why some things are not done by rolling update, because > replacing dozens of applications and libraries, and potentially breaking > other stuff on your system, is going to cause more problems than it solves. I understand about libraries. What part of that don't you get? I'm not getting into a flame war here. Fedora upgrades libraries all the time, correct? Yes. And how does it handle those library upgrades? It seems to handle them very well. So, all that effort into that paragraph went for nothing. Libraries HAVE to be upgraded. So? Apps break when libraries are upgraded unless built against them. That's elementary. So if it's that damn hard to upgrade libraries how does any distro manage? My goodness, there must be SOME way to do it. > >>> - 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. >> >> What does this have to do with rolling updates? We are talking about a >> specific distribution here. That should have been understood, I would >> have thought. Under no circumstances would I try to use a Fedora RPM on >> my gentoo box. So this bit is irrelevant. >> > It's not irrelevant, you just don't understand it. If you have run FC8, > and 9, and 10, and maybe 11-alpha, you know they boot differently, > behave differently, and need a lot of internal files changed. These are > distributions of Fedora, and they didn't go through gentoo or Window98SE > or Beverly Hills CA. And if you are going to say that's releases not > distributions, I left your own comment about semantics, and people who > argue over them, intact. It is irrelevant when considered for a specific distribution. I'm not talking cross updating. File locations change, oot processes change. I've moved to udev in Gentoo just fine without the need for an upgrade from the version of Fedora without it and the one with it. (Which versions escape me.) It CAN be done. Those types of changes can be managed in a rolling update environment. So, again, what does that matter? See, I don't think you quite understand. You've continued to give me the same reasons everyone else has, just more verbose and less coherent. Feature changes, file locations, BOOT processes can be managed within a rolling update context. I know it can, I do it all the time in Gentoo. They are, possibly, the only example out there that works. But it does work. It's quite obvious you don't want or like the idea of rolling updates. Fine. I mentioned it in the original thread because I like it and it works, and works quite well. I personally don't care if you like it or not. I also personally don't care for your tone in this reply either. I've tried to keep this a civil and intellectual debate. And now we're down to people having temper tantrums. Get over it. I don't agree with your arguments. To me they are specious at best and downright wrong at worst. > > . >>> 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. >> >> Compiling only is important to a distro that compiles from source >> everything. Fedora builds binaries and makes the binaries available. >> So exactly HOW does Fedora handle GCC updates? Surely they are not >> using the same GCC as FC1 used? I suppose it's possible they move to a >> new GCC for a new release and not in the middle of a release, unless >> it's a rev update and not a major version. Again, I mentioned >> 'profiles' in Gentoo. For me, F10 is a 'checkpoint' of versions and >> libraries from which the new updates are going to build on. The concept >> is the same in Gentoo. Granted I control updating GCC and for a major >> update (which I did last week) I had to rebuild the entire system for >> the libs to all be the same GCC version. >> > Now we have "checkpoint" and "release" in play (semantics), and gentoo > let's you build everything, hopefully in the right order. > >> So, let's assume rolling updates from F9 to F10. All an 'upgrade' does >> is setup the baseline binaries and libraries that F9 must have on it to >> qualify for F10 status. Sure, there are 'release' files in /etc/ but >> that's irrelevant for the purposes of this discussion. > Anything which explains why full releases are easier for the users is > irrelevant to your discussion... Again, who said they are easier for users? I'm a user, I don't have a problem with it. I run several Gentoo desktops and the user doesn't notice the difference. I would think not having to pull down an ISO and upgrade every few months would be easier than having to. Obviously, some people enjoy doing that. I'm glad to see preupgrade and PackageKit coming along. It's about time Fedora has a mechanism in place that a new distro like Ubuntu has had almost since inception. Fedora has been around (and RH) a lot longer and is just now getting to that. > >> No, what's the difference between I manually updating my F9 system to >> the exact same versions and kernels, etc that F10 shipped with? And >> upgrading to F10? Wouldn't my F9 box be F10 in all but name? I >> certainly think so. In fact, isn't that what preupgrade does? Or the >> apt-get method in Ubuntu? >> > Here you are mostly right, you can update thing piecemeal to F10 > versions, but the machine would not be F10 unless you updated all those > files in /etc/ you found irrelevant, because it would use F9 process > flows in boot, would never upgrade other than manually because the > revision is part of the update process. So you really have to do the > whole thing to get smooth operation after the fact. They are relevant only from the standpoint that they (like profiles in Gentoo) checkpoint the baseline for the system. That's all. > > I write this on a virtual machine which is RH8 slowly upgraded and > hacked to FC9. It is not a path the average user wants to follow! I did > two FC9->FC10 upgrades and two preinstalls around here, and the full > installs took no longer and had less little cruft around to annoy me. > Note, I have been doing computers for decades and did the install > originally so I could keep the important parts in separate file systems, > and everything I changed in /etc/ was under RCS so I could get a true > reading on what I changed and not forget anything. > >>>>> 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. >> >> I'm not sure I agree that it's less painful. I have to take down my >> servers to do an upgrade from Fedora. With preupgrade I can keep the >> system up during a large portion of the upgrade process and that's >> better. I don't know we'll ever get to the point where we don't have to >> reboot to get the latest kernel, but I'm hopeful. >> > If you have a *LOT* of brass appendages you can do it with kexec. It > even works sometime, although the system may or may not remain useful > during the process. Yeah, I've run kexec for a while now. It's got promise, but I don't totally trust it yet. > >> Again, new releases are fine. Gentoo has releases as well. They are >> just not as painful a process to 'upgrade' to. Sure, it's a different >> designed distro altogether. compiling from source eases and complicates >> things in different ways than binary offerings. A checkpoint to me is >> still a checkpoint. I'd really like to see Fedora work more toward >> streamlining the 'upgrade' process online instead of relying on DVD >> ISOs, etc. >> > I've noted that some upgrade require changing a lot of things at once > and may break things which are shipped with Fedora. If you want a less > painful upgrade leave room for a virtual machine with disk enough to run > the root and boot partitions, install and test in that and then reboot > it live. And by "test" I mean run live load on it, if it's a server. > Then the cutover is just a reboot away. > As I noted before, I've done this very thing with VMs and it works pretty well. But, speaking of easy for the users, how is that easy for the users 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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
