Linux.com

3 hours and my (working notebook) is complete image of my old notebook. And I've installed even more than previous had.

All my preferences, including my own theme, my spatial nautilus windows, mail accounts, bookmarks, C# and pascal projects worked like a charm.

btw. I exchange my notebook for every new distro (started this ritual with RH 6.2) and not even once there was a problem. Speed gain with FC3 is enormous.

#

All my linux life (since 1993) I've been on the bleeding edge. I've spent years logging bugs and upgrading, downgrading. and to be honest I'm quite tired of wasting my time on immature software. problem is that even RHEL 3.0 and SUSE SLES9 are immature for desktope usage. KDE and GNOME still have shitloads of bugs. I can still trigger a bug in about 2 minutes.

Just today both Gnome volumecontrol and eggcups dumped core on me big time.

With FC3 I found a regression bug with my pcmcia controller. prism54 cards will not register the last two octets in the mac-address.

So linux is just as bug ridden as windows.

The server side is great though.

#

Upgrading to a beta or claimed-to-be-stable-but-not-quite (e.g. Firefox, Thunderbird) is simply not preferred by most users.

On Debian or Debian-like systems, you just fill in or and you upgrade to that release. You can backup config files as well.

#

The following will work, but only for those who have the skill to do it. Won't work for granma. Since this is a newsforge post, granma will probably not see it.

Make separate partitions for<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local. Just as you would for<nobr> <wbr></nobr>/home.

Don't mount them when you install, or upgrade your system. After your new system install(upgrade) is done, go to<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local, do an rm -rvf<nobr> <wbr></nobr>./*. Mount your old partitions under<nobr> <wbr></nobr>/opt or/usr/local. Or, if you are finicky about standards mount old locations at<nobr> <wbr></nobr>/olddir and just make links, for example with: ln -s<nobr> <wbr></nobr>/olddir<nobr> <wbr></nobr>/opt
I have done this a number of times with new installs, upgrades and even while switching distributions.

Still, I can't see why distributions can't ask the user if they want you to leave<nobr> <wbr></nobr>/home<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local alone if these are found during an install or upgrade and do as per your input.

#

Create partitions for anything you want to control yourself during your initial install.<nobr> <wbr></nobr>/home,<nobr> <wbr></nobr>/opt, and<nobr> <wbr></nobr>/usr/local are obvious choices. When you do a new install, uncheck the box that says to format these partitions and you'll keep the old contents.

#

1) # apt-get dist-upgrade
2) (coffee break)
3) upgrade complete

I won't go into blow-by-blow details, as I don't think you want to hear them all again, but, really, I could not help but cite an immediate Debian solution to every single gripe you list in the article.

Debian has mastered the art of package management so well that it's barely a distribution any more - it's a base distro from which other distros build on. Linspire, Xandros, Knoppix (and it's boiundless progeny), Progeny, Ubuntu, Libranet... all these are based on Debian. Take your pick.

Why trust a commercial entity to maintain your Free Software?

#

Eheheh! I do the same every day. In fact, I upgrade my linux distro (debian) every day. In the end, I do "apt-get clean".

#

I've remotely upgraded two machines from Debian Woody to Ubuntu Warty seamlessly. All I had to do was update the apt sources.list, apt-get update; apt-get dist-upgrade... and presto I had a new Debian-based system.

When I read articles like this one, I struggle to understand why anyone would want to install an RPM off some stray internet site when it makes so much more sense to let your distributor do the packaging for you and install a copy of the application that is already tweaked to work with your distribution.

#

urpmi.removemedia -a
urpmi.addmedia main [path-to-new-main]
urpmi.addmedia contrib [path-to-new-contrib]
urpmi.addmedia --update updates [path-to-new-update]
urpmi urpmi
urpmi --auto-select
urpmi kernel

#

maybe i've just been using debian too long, but seems like a lot of commands and doesn't make as much sense to me as one apt-get dist-upgrade, not too mention I've found debian has the biggest repository of packages over any other distro.

#

Actually, in the example only the last two commands are the ones used - the ones above are used for establishing the repositories. So this is what a Deb user would already have done by editing<nobr> <wbr></nobr>/etc/apt/sources.list.
One could argue that "sudo/su urpmi filename" is actally a faster command than "sudo/su apt-get install filename".
With Mandrake's "urpmi --auto-select" you get the same effect as with dist-upgrade.

#

Except that it isn't even close to being as good as apt. urpmi fails too much.

#

You assume that Debain will work out of the box, or should I say download. Fedora works with my graphics card right after install. I played with, aka sought help on the message boards and websites, debian for hours before giving up. I have an nVidia card and it would not let me get a resolution greater then 800x600, yet I run at least 1024x768 with fedora.

If I had my way, I would run debian, but given that I don't have hours to waste just to get my video card to work right, what am I left to do.

#

Have you tried the new installer? I suggest you do.

#

You *want* to switch to Debian. I know you do, I see it in you.<nobr> <wbr></nobr>:)

Why don't you copy over your Fedora XF86Config (Debian names it XF86Config-4, btw) and start from there. There is the nvidia-glx packages, or the nvidia-kernel package. Give it another try, and if you have trouble, you can google the numerous 'Fool-proof nVidia installation with Debian' guides there are. Also available are the friendly people in irc.freenode.net's #debian and #nvidia channels. I know Debian may be a bit difficult at times, but once you get set up, it is the greatest thing in the world. Seriously. you get the newness and cutting-edge of Fedora with Debian Sid, and none of the new-release breakage you get with Fedora. Good Luck!

#

Friendly people in #debian on irc.freenode.net? Excuse my hollow laughter<nobr> <wbr></nobr>....

#

well some (non-avian varieties) are....and if not, #ubuntu and #mepis are filled with less abrasive individuals (prob #knoppix too)

#

1) # apt-get dist-upgrade
2) (coffee break)
3) upgrade complete

I won't go into blow-by-blow details, as I don't think you want to hear them all again, but, really, I could not help but cite an immediate Debian solution to every single gripe you list in the article.

er... you can do all of this with redhat, or suse for that matter - install apt, and away you go. I've upgraded a number of redhat 8 or 9 boxes to fc1 like that, and many have upgraded suse 8 to suse 9 etc in the same way. Thanks for apt, debian, it was one thing you got right....

#

apt is only one part. Another part is biggest repository so you don't need install any software outside Debian repository. Yet another part is seamless upgrade and that any package plays nice vith any other package.

#

APT whas not made by Debian Developper , the deb package yes , but not apt or dpkg.

#

One wonders how you reached such a conclusion:


<A HREF="http://en.wikipedia.org/wiki/Dpkg" title="wikipedia.org">http://en.wikipedia.org/wiki/Dpkg</a wikipedia.org>


<A HREF="http://www.chiark.greenend.org.uk/~ian/software/" title="greenend.org.uk">http://www.chiark.greenend.org.uk/~ian/software/</a greenend.org.uk>


<A HREF="http://www.advogato.org/person/jgg/" title="advogato.org">http://www.advogato.org/person/jgg/</a advogato.org>




So, I think we all know the truth now.

#

"One wonders how you reached such a conclusion:"

1) I whas alive and old enough when it whas created and remember the details. 2)I can read changelog 3) Its a funny tidbit I use to show the force of open source and the GPL. 3) I seem to have the ability to read text in english and you obviously dont.

"So, I think we all know the truth now."

Yes , you dont know jack and cant read<nobr> <wbr></nobr>... Nothing new in your case.

http://en.wikipedia.org/wiki/Dpkg

"dpkg is the base of the Debian package management system. It was created by Ian Jackson in 1993"

I like the "dpkg is the base of the Debian package management system." , meaning it whas created/built then used to build the Debian project<nobr> <wbr></nobr>...

http://www.debian.org/intro/about#history

"Debian was begun in August 1993 by Ian Murdock"

http://www.chiark.greenend.org.uk/~ian/software/

"I wrote the current implementation of dpkg"

I like the " current implementation " : it means its a rewrite/revision of a former version<nobr> <wbr></nobr>...

"I am the primary author of Debian APT"

I like the "Debian APT" : meaning there whas an APT and then a Debian APT and then Apt-get.

If I recall history right Dpkg whas built for Slackware wich refused it and then Apt whas built to use dpkg and then The Debian project whas created in August 1993.

To resume : DPKG and APT where not built by or for the Debian project but they picked it later used it and improved it.

#

You missed his whole point. I mean if you install a distro, and then upgrade that distro's software anything works well. His frustration is with third party software. It is with things that don't belong with the distro. Debian doesn't fix the problem. Gentoo doesn't fix the problem. They only work for standard software. I agree with the user that it is unbelievable that RealPlayer wants to live in<nobr> <wbr></nobr>/usr/bin. It should be in<nobr> <wbr></nobr>/opt.
Most third party software packages do not work with native package formats, becuase there are too many of them. I work with a custom software package, and the developers need it to work on the maximum number of distributions, so they wrote a custom shell script for installation. That shouldn't have to be the case.

I realize that Debian people want everything to be free, and that Gentoo wants everything to be natively compiled, but the package that I have been dealing with has dependancies on commercial tool kits to do three-dimensional rendering, and there is no open source equivelent. Compilation by end users is not an option.

#

Why trust a commercial entity to maintain your Free Software?

I give courses on Linux, and I found out only one reason to do this : certifications for certain hardware and software.

For the rest, I also find that Debian is the best, although I need to run RH9 on my server, because it is the only distribution which has a kernel that supports the Promise SX6000 controller.

But that should be fixed according to Markus Lidel, who maintains the I2O subsystem.

If this works, then midrange server hardware is not exclusive for Red Hat and SUSE anymore.

#

Worse than the location of files installed by 3rd party packagers is the name of the package itself. If all RPM packaged versions of the same program used the same name conventions you could update any version with any other and the internal information would tell them what to remove/replace and you wouldn't have to worry about where the components landed. I think a body similar to the FHS should manage RPM package names and 3rd party packages that are done ahead of those bundled with a distribution should register their names on a first-come-first-served basis. Then if the distribution packagers refuse to use the same convention they can at least 'obsolete' the other to avoid conflicts.

#

The standard is maintained by <A HREF="http://www.lanana.org/" title="lanana.org">LANANA</a lanana.org>. It is part of the Free Standards Group--the same folks who bring you the Linux Standards Base (LSB). IIRC if you want to make a cross-distro, fully LSB v2-compliant RPM package you must follow both the FHS and LANANA conventions.

By the way, a distro need only be able to properly install and run LSB packages to be LSB compliant, so a properly configured Debian-based system with RPM installed can be LSB compliant even though it has a full compliment of native debian packages installed which do not comply with FHS for example. Just as long as it plays nice with others. In fact the only LSB and FHS compliant distro that I am aware of is the LSB's own "sample implementation" which is pretty rudimentary and only meant as a reference/testing platform.

#

Fedora is built of leading-edge package releases. It's not designed for seamless upgrades, because they have a fast release schedule that is focused on putting out an up-to-date system, not backwards compatibility. Things change, things break. If you want a distribution with a dependable upgrade path, you want Debian, the queen of upgradable distributions. And there are doubtless other distros that you can upgrade dependably. But don't expect it from Fedora.

#

I've upgraded my and several other Fedora boxes with no problems whatsoever from 1 to 2 to 3. That's not a guarantee that every box ever made will work perfectly when upgrading but Red Hat has always been pretty good about upgrades. Unless you want to run the ever outdated Debian stable there is a also a chance that Debian will break from time to time as well. No OS updates perfectly ever single time.

I have to say its really annoying to have to constantly hear people say things that aren't true about Red hat and Fedora. You prefer Debian fine. But don't lie about Fedora in order to push your own agenda.

#

Lying, heh, spoken like a true fanboy who counts anything he does not wish to hear as a lie. I speak from experience. You simply cannot count on Fedora to upgrade reliably. Sometimes it does, sometimes it doesn't. Many loyal Fedora users will tell you the same thing. We still like it and use it, and don't get all ticked off when someone dares to admit it might not be perfect.

#

I am a different fanboy than the last one that posted.

I was a debian user for years. I switched to Red Hat and then Fedora. It upgrades nearly as reliably as debian. Not as reliably as debian stable, but that is not a fair comparison. Fedora is not addressing that "market". It is addressing about the same market as debian "testing" or "unstable".

Doesn't matter. I like Red Hat and Fedora better. I just do. And it is just as "free" as debian - and the good folks of Red Hat are trying very hard to incorporate community involvement as best as they can.

Debian, progeny, gentoo, susu, etc., etc. - I wish you well. Diversity!

#

Upgrade fedora-release and yum together
yum upgrade
wait

One box I have sitting on a secure network is running FC3 and has a 430 day uptime. It started at Red Hat 9 and its now (except for the kernel) running FC3 without major downtime and without a reboot.

#

with Gentoo

emerge --sync
emerge -uD world

#

Yes I do know that gentoo takes a helluva lot of time to be compiled and installed on a system..but the bright side is that the system which you have will be very easy to update. The portage tree has been well built as well as the applications which go along with it. Thats one of the main reason why I shifted from FC1 to Gentoo 2004.3

#

Exactly. I do:

emerge --sync
# Check what will be updated
emerge -Dup world
# Install updates
emerge -Du world

I do it between every 1 and 5 days. When the next "version" comes out you are already upgraded to it.

#

I just started with Gentoo, and a stage 1 install can take along time. But, for me, the speed gain and stability compared to a binary distro is well worth the time investment. If you want a high performance server or workstation or if you just want to revive old hardware and have it perform better than today's hardware with binary distros, then Gentoo is worth considering.

And the upgrade process, so far, has been painless.

#

Well, I see your points, and I know them from when I used SuSE. But then I decided to try something new.
So after browsing and thinking a lot, I decided to try gentoo.

Forget about distro-upgrades. I have had the same system for a long time now. It has survived an XFree to Xorg-change, several revisions of gnome, kernels, gcc etc.

All without more problems that I've encountered with a normal RPM-based installation.

I'm not saying gentoo is teh bomb because it's source-based, or the possibility for optimizing everything.

It's good because the developers did something new. They decided to change their mentality about updates. Instead of re-inventing the entire system every 6 months or whatever, they made it possible for the system to be upgraded dynamicly.

Distro-wars aside, we need more developers to think out of the box. Yes, we have a long tradition in software-history for patches and updates. But why should we keep it that way, when the internet gives us other possibilities?

#

Actually, when I used Mandrake, the RPMs were far from current versions. I use Ubuntu now and experience the same. So I usually just download the source packages and put as much as possible in<nobr> <wbr></nobr>/opt/.

#

Like n8o and others said before me, Debian provides the solution to all of the points you mention.
I went 4 years without reinstalling my main workstation. A daily cron job uses Apt to mail me a list of packages ready to be upgraded to the latest "testing" version. I've discovered that packages in Debian's testing branch are generally at the same level as RedHat/Fedora. Usually I can safely run the upgrade and my config files remain untouched (or at least sane) and if I stick to woody for the servers, the software versions remain the same, so no incompatible changes are introduced.
Besides that, Debian includes almost every single Linux app you will ever need as a part of the distribution proper. I believe that in it self eliminates your points regarding<nobr> <wbr></nobr>/usr/local and<nobr> <wbr></nobr>/opt. Those directories are almost empty for me, except VMWare, Skype and some custom scripts I wrote.
The few times where I was forced to use RedHat, it managed to severely f*ck up. Just this week I up2dated X11 for a RedHat 9 setup I use for development, and it actually nuked my XF86Config which was tuned to this exact hardware. That sort of crap just takes me back to the old Win98 days when my patience with DOS finally ran out.

Take my advice and switch away from RedHat based distros. You'll save yourself a lot of hair.

#

How come totally ignorant people [on long existing other linux distributions out there] come to post such articles on such a site.

If he'd know anything from around gentoo and debian and their many variants, he'd know the problems he mentions really don't exist - only if you don't know or don't eant to know that you picked the wrong piece of crap from the bag to play with.

With Fedora, you're like on the edge: it's good to try out new stuff, but there are very cool and easy live distros for this purpose, but it's hard to work with in a long term, and it really doesn't support update-ing, only the hard way: the you-figure-it-out way.

So drop all that crap and start using a distro, which actually makes your life easier. I'm not a masochist, not in any imaginable way, I really can appricate simple but well working stuff, and my main linux OS is Debian for many years now. Others come and go, I'm trying many others from time to time, but for an easily managable machine I have only one that counts, and that is not Fedora or Redhat.

#

I second that! I almost thought I was reading an article about upgrading Windows! On my main work PC I clean installed ONCE! That was version v6.2 of Red Hat Linux. Since then I have upgraded every release of RHL and now Fedora.

Add to that the fact that this is my 3rd PC since installing Linux and now you can really see where it blows Windows out of the water. I have upgraded the OS 6 times and transfered it to a new PC 2 times. My preferences were rarely ever changed and when they were there was an<nobr> <wbr></nobr>/etc/whatever.conf.rpmsave file there with the old ones.

I'm sorry but I just can't share your experience or recommendations! Even a clean install can be pretty painless. My home PC has had several clean installs since I try out different distros from time to time. Usually a backup of the old<nobr> <wbr></nobr>/etc directory will give you everything you need to restore old prefs and settings.

Better yet, use Gentoo or Debian and you kind of forget what an OS upgrade (and software upgrades for that matter) is/are like.

#

From my reading of the file hierarchy I interpret<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local to contain the following:

<nobr> <wbr></nobr>/opt - packages (rpm, tar, etc) of third-party software.

<nobr> <wbr></nobr>/usr/local - all local applications not in the distribution, including the output of the<nobr> <wbr></nobr>/opt packages after installation utilities are run.

In this way<nobr> <wbr></nobr>/opt becomes a third-party package management locale rather than an executable location.

Finally, developers need to do better at detecting and adding/using libraries for their software. In my mind a package should contain everything needed to run an application, and the make files/package files should handle the details of compatability for the end user - loading a library only if a compatible version does not exist, and creating a new directory, rather than overwriting an existing installation. Upon seeing this it should build the application configuration file to take this into account instead of using the LIBPATH etc. environmental variables stupidly. This could be as easy as putting a 'LIB=/mylib/dir' to the file - and using that, rather than the environmental defaults if so found. 90% of my headaches integrating non-standard packages into distributions would be solved if everyone did this.

#

No problem - yet

I have upgraded 1 presario x1000 laptop, an 5 desktops (compaq, koobox, microtel, homebuilt) without any grief.

My laptop runs windozeXP, simplyMEPIS, and FC3 which is my default - and I have dual boots using SuSE9.1 and Debian ( but all use FC3 ).

I like apt and yum but not up2date.

I use perl php java eclipse mysql phpmyadmin apache mozill daily. I only use XP to apply patches.

I did a FC3 clean install on one of my desktops - just to see if things were noticably better - they were not.

I have been using linux for 9 years - but maybe I am still having too much fun with it to realize I am having problems?

Anyway I do know that FC3 should not be as stable as it is for me<nobr> <wbr></nobr>.. and the Debian advice is probably good ( and you will like apt - I guarantee it )

#

Mandrake 10.1 the Windows Me of linux.
Another 100mb + upgrade that borked the internet connection, the mouse, the firewall,ssl,ssh,Kde,file permissions,and so slow.
I grew tired of the awful quality checking of the offered rpms. Back to DEBIAN. urpmi auto-select looks good but the packages are very poorly checked for useability!!!!

I am spoiled by the quality of DEBIAN

#

I or anyone who is running MDK 10.1 Official cannnot and will not believe a sigle word of your lies.

It is super stable. You do no favors to Debian by inventing problems where they don't exist. There are plenty of things that Debian does very well, among others, it has several years worth of security updates for the stable release, which is not something that the non-corporate version of Mandrake can claim. But for a desktop, give me Mandrake any day.

Debian is only usable for a desktop if you are using sid and sid break often and badly.

#

urpmi --auto-select
cofee break
Mandrake upgrade complete, well, minus picking a new kernel. Just as nice as debian IMHO.

Article author is obviously clueless.

#

apt-get > urpmi

While apt-get has always worked flawlessly for me, urpmi has given me nothing but headaches. I can't remember the last time I sat back and watched it perform a distribution-wide upgrade and not fail miserably at more than one step along the way. Yes, I've tried it with Mandrake too. It didn't work for me. Maybe you have different results, but meanwhile I'll stick to the tested and true apt-get.

#

I'd reiterate what others have said about distros that handle this better, such as Debian. I installed Debian on my laptop over a year ago and stay up to date with simple upgrades once a week or whenever I feel like it.

I installed Debian on my server 160 days ago. I know this because that's its current uptime. After I installed Debian, it's never needed to go down and stays up to date with security patches effortlessly.

Debian's long-time weakness has been the difficulty of that first install. If they ever put out an official Sarge release that uses the Anaconda installer (and tell people about synaptic), I expect to see converts in droves.

#

If they ever put out an official Sarge release that uses the Anaconda installer (and tell people about synaptic), I expect to see converts in droves.

Not necessary. The new Debian installer may be text-based right now, but it is so easy it had me up and running in no time. I was pleasantly surprised as my previous brief experience with the old one had me running back screaming towards SUSE.

For now the installer is textbased, but it has provisions to accept graphical front-ends. Expect debian to get a lot of interest in the coming two years.

Apt is the way software installationn should have been done on GNU/linux from day one. (I've been told that Yum practically does the same).

#

fux

#

I have to join with the Gentoo and Debian users. All these problems just don't exist with Slackware.

Installer completely removes software - No.
Improper use of<nobr> <wbr></nobr>/usr - Sometimes, but almost always avoidable, and, if not, irrelevant to (untouched by) the upgrade process.
Failure to use<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local correctly - No. And I have stuff in<nobr> <wbr></nobr>/usr/local that has survived in working order through many upgrades.
Configuration files in<nobr> <wbr></nobr>/home and<nobr> <wbr></nobr>/etc getting clobbered - No.

The upgrade from Slack 9.1 to 10 took 30 minutes, with none of the hassles described in this article. Redhat/Fedora is not Linux.

#

To add to your remark, upgrade through swaret only required me to change
VERSION=9.1
to
VERSION=10.0
in<nobr> <wbr></nobr>/etc/swaret.conf

Upgrade in Current is sometime broken, but it is what Current is made for, isn't it ?

Anyway, for me Slack is the way to go.

--
Goupil, 10 years of happy slacking

#

I think you'll find these problems don't exist on Fedora either than the 'problems' of an RPM-based distro are purely the result of believing poorly written and almost wholey inaccurate rants like the original post.

For the record by FC3 installation dates back to a RH9 install several years ago, I use Dag Wiers, Freshrpms and the like and each of the major third-party apps packages *do* work together to ensure thier apps are compatably packaged.

#

RPM based distros suck.

1) Put<nobr> <wbr></nobr>/opt &<nobr> <wbr></nobr>/usr/local on separate partitions and,

2)

  a) If you want everything done for you, use Debian.


  b) If you got the cajones to manage & maintain your system yourself, use Slackware.

Either way, updating is no problemo

#

I use debian.

#

This is one of the many reasons I am so happy I found Arch Linux. There is no need to "upgrade" when a new "version" comes out. Instead it follows the rolling release and does wonders. I run one simple command whenever I wish, and any outdated packages installed by the distro and automatically upgraded. Reinstalls unnecessary.

#

FreeBSD...
make world (upgrades the whole OS)
portupgrade (use it for update your apps, whether compiling or as binary packages). it works very well. remember: there are more than 12,000 apps in the FreeBSD ports!

back up before upgrading!

#

I really wouldn't use FreeBSD as a shining example of easy updates. Security updates for packages in the base system are much more difficult than they should be. Distro upgrades often break the system entirely.

Installing and upgrading ports is wonderful most of the time, but it is the base system that doesn't always go that well. I've had much better luck with upgrades using Gentoo, Debian, and Mandrake than I have with FreeBSD.

#

The problem of preserving locally-installed and locally-created software and date is trivially solved by putting them all on a fileserver. Mount<nobr> <wbr></nobr>/home,<nobr> <wbr></nobr>/opt,<nobr> <wbr></nobr>/usr/local, and<nobr> <wbr></nobr>/var/mail after you're done with the install.

When doing a major upgrade on a server, I usually do a clean install onto a separate partition (or a different machine altogether, especially if it's the firewall); that way I always have a working system to fall back on. After that I can spend a week or two in a chroot getting it right.

Of course, these days I mostly just do

<TT>apt-get dist-upgrade</TT>

but it's fun to play with new distributions every once in a while.

#

Most of the problems you've outlined here are specific to RPM-based distributions. Change to something non RPM-based, and I'm guessing you won't have the problems. From my own experience, I know Linux From Scratch in particular (what I use) isn't that difficult, depending on what it is you want to upgrade. For kernel upgrades, simply recompile the kernel/whatever other modules you need, and reboot. For application upgrades, I usually install most stuff in<nobr> <wbr></nobr>/opt...then to upgrade you can just delete<nobr> <wbr></nobr>/opt/myapp and reinstall the application in question.

For toolchain upgrades, it's a bit more complex...but not much necessarily. Make sure you've got a list of your applications, though. Then...
1) Backup your data...documents, dotfiles and so on. It's generally a good idea to have worked out some conventions for your system first with regards to where these files are kept. say ~/my_documents and so on.

2) Rebuild toolchain/base system.
3) Reinstall applications.

You'll get an upgraded system, mangle free. I realise that you might look at this and scream in horror about such things as dependency hell and so on...but in my experience dep hell was actually worse on an RPM based system than it was compiling from source...simply because RPMs have a tendency to generate additional version errors as well. I'm also assuming that since you're posting on Newsforge, you've got enough of a clue technically that you'd be able to compile an LFS system...although it really isn't all that difficult. I had to learn some sh before I became totally confident, but after that I was fine.

#

For kernel upgrades, simply recompile the kernel/whatever other modules you need, and reboot.

Hmmm... "simply recompile the kernel"? For you and me maybe but not everyone is a propeller-head. A typical PC user would not find such things simple at all. I've never seen Joe-Mac-user recompile hus kernel...ever. Jane-WinXP-user can barely manage Windows Update sometimes, much less the involved kernel and toolchain upgrade processes you mention.

I think the authors point is that distro developers should put some effort into interoperability and ease-of-maintenance do that the mainstream user will feel more comfortable with adopting a Linus platform. I'm not sure a lot of readers "get it"--yum, up2date, urpmi, apt-get, emerge etc etc are all very nifty and all, but nothing in the Linux world is quite out-of-the-box point-and-click refined as Windows Update (which is a good thing for MS I guess because non-updated WinXP is basically unusable on the 'net without outside assistance in this win-virus-infested age).

Really, you wouldn't expect a typical car owner to "simply get ring and gasket kits and rebuild the top end", or most homeowners to "just run another drain line to the soil stack for your new kitchen sink". If everybody were inclined to do such things themselves then mechanics and plumbers would not exist. So unless we can do far better than "simply recompile the kernel" then Linux will have to settle for the enthusiast and some niche enterprise markets where professionals are available to contend with complicated upgrading, maintenance and interoperability issues.

#

Get another distro, sir. Red Hat and Fedora are bloated carcasses full of rancid shit like this packaging deficiency you mention, and a million others. Plus you still have to deal with RPM, even if everybody loves the "standards" as much as you do.
Try something else, please, because the problem's been solved for years already.

#

There must be a misunderstanding here.

From the days when booting up a machine involved using a smaller disk local to that machine, and then a larger disk somewhere out in the network for all the user stuff --

"/bin" - everything to get the system up and running, booted - binaries that regular users might use.

"/sbin" - everything to get the system up and running, booted - fixed, perhaps, if broken - binaries that regular users will never need, superuser-type binaries only.

"/usr/bin" - historically, this would have been the network-mounted disk - binaries for regular users that are not needed to boot the system

"/usr/sbin" - again, could be on a larger disk somewhere else - binaries that regular users will never need (superuser-type binaries), but binaries that are not needed to boot/fix the system.

Maybe I misunderstood, but that's where stuff is supposed to go. So<nobr> <wbr></nobr>/opt is for "local system administrator" use - I suppose you could interpret that as something that would be compiled from source locally, specifically for that business, like custom business app or some other custom app. You could say that rpm stands for "Red Hat Package Manager", so since "Red Hat" is a distro, the files go into<nobr> <wbr></nobr>/usr. I think the FHS definition of<nobr> <wbr></nobr>/opt could definitely be understood as someplace where custom built/modified compile from source stuff or "I paid $10,000 for this software" type stuff would go. If it's rpm, it's distro? Seems like that's what going on here. That's why the Debian<nobr> <wbr></nobr>/etc/apt/sources.list file is so cool - you just put that third party repository's ftp/http website URL in there and it officially registers all the deb files on your machine and upgrades them, too, when new ones come out. It's totally wonderful.

I also have to echo the Debian thing - I have a number of Debian machines for myself and friends/family and the upgrades are generally very straightforward. An occasional problem might require some fixing and a minor panic attack session, but it's usually something that's pretty easy to fix.

#

We are supposed to be professionals. You should have a working and tested backup strategy that would allow you to restore a working system onto bare metal, to cope with flat building disasters. Then you could modify the process to cope with minor problems like an upgrade, or recover from a failed upgrade. Blaming distro differences is not a solution.

#

if you take the official OpenOffice.org files from http://www.openoffice.org then<nobr> <wbr></nobr>/opt is used as default location for the installation.

in OOo 1.1.x you use setup -net for preparing the 'network side' installation and start setup from within the<nobr> <wbr></nobr>/opt/openoffice*/program directory as user to get the user configuration data installed

in OOo 1.9.x developer snapshots the rpm archives can be --prefix'ed as the rpm files have been prepared to be relocatable

Even a relocated installation is possible but there's one bug within FC3 which prevents this but there's a workaround:

just create an init script in<nobr> <wbr></nobr>/etc/init.d and link it within the rc.3 or rc.5 directories

#!/bin/sh
touch<nobr> <wbr></nobr>/var/lock/rpm/transaction
chmod 666<nobr> <wbr></nobr>/var/lock/rpm/transaction

#

What I do on my home machine is set up completely independent copies of, say, Fedora Core 2 and Fedora Core 3 (which is my current config) - and, unlike I bet a lot of people do, I *don't* share the<nobr> <wbr></nobr>/home trees (I just create a<nobr> <wbr></nobr>/home inside each respective partition). Yes, it does mean I have to copy some of my customisations over, but it gives me a totally clean downgrade path, which sharing<nobr> <wbr></nobr>/home across two versions of a distro does *not* do. I've found that programs in the later distro tend to modify<nobr> <wbr></nobr>/home config files in such a way that can break some of the apps in the older distro.

I always, always, always take the cold install route onto another partition as my "upgrade" route - using the "Upgrade" in anaconda is a one-way street that always has the risk of mangling things.

BTW, Fedora Core 2 is effectively a "milestone" release (the first ever release from the Red Hat/Fedora family to use the 2.6 kernel), so as long as they keep releasing updates (eventually via the legacy project), I see absolutely no reason to jump to FC3 yet. In fact, at work, I'm not intending to move from FC2 until a kernel 2.8-based FC release comes out, which I reckon will be in about 2 years.

#

I've had a good laugh at your problems<nobr> <wbr></nobr>:-) After reading your list I can see that nothing has changed since RedHat 5.x days and these problems are why, after N-th clean reinstall, I decided to dump this broken distro.

You write:

There are plenty of valid reasons not to upgrade to the latest release of your Linux distribution. You have to reapply all manner of preferences, hunt around in the new Applications menus to find where your programs have moved to and what they're called this time around, get used to new ways of doing the simplest tasks, and there's usually a new firewall subsystem to boot. But the one that has always gotten under my skin is the fact that upgrading my distro always breaks the add-on software I've installed myself.

Gee, just move on to some REALLY easy to use and, even more important, upgrade distro. Like Debian for example. Since moving to Debian 5 years ago I almost forgot what does it mean to have problems with upgrading and 'RPM dependency hell' is a nightmare of the past. I've had to reinstall system once in that time because of a disk crash, and it's always clean and usable after all this time regardless of how many packages I install/uninstall or how many times I upgrade the system.

#

* Every application project that offers independent downloads should package their RPMs to install in<nobr> <wbr></nobr>/usr/local.

No! There are a bunch of different base paths, like<nobr> <wbr></nobr><tt>/</tt>+<tt>/usr</tt>,<nobr> <wbr></nobr><tt>/usr/local</tt>,<nobr> <wbr></nobr><tt>/opt</tt>,<nobr> <wbr></nobr><tt>/pkg</tt> and so on. These should be handled by different *mechanisms*, not different packagers. Most importantly, RPMs should never ever touch<nobr> <wbr></nobr><tt>/usr/local</tt>. That's where files ends up if you<nobr> <wbr></nobr><tt>./configure && make && make intall</tt>, and you must keep those files separate from the RPMs, or you end up with an unmaintainable mess.

* Third-party repositories should package their RPMs to install in<nobr> <wbr></nobr>/opt, under their own subdirectory.

No! It won't solve any problems. The third party packages should be well integrated in the distro, or not be installed at all. And it shouldn't change it's install location based on who did the packaging.

* Distros should stick fast to the FHS definition of<nobr> <wbr></nobr>/opt and<nobr> <wbr></nobr>/usr/local, and never touch them.

And so they do. So that you can install Matlab in<nobr> <wbr></nobr><tt>/opt</tt> and that Firefox tarball in<nobr> <wbr></nobr><tt>/usr/local</tt> without worrying about overwriting or being overwritten by RPMs.

The situation just isn't as bad as you make it out to be. Just use non-sucky repos.

#

I use Mandrake 9.2 on my main computer. I quite often upgrade items that were originally supplied in a Mandrake rpm package. My trick is to get the source, compile for installation into<nobr> <wbr></nobr>/usr/local (or anywhere else - such as<nobr> <wbr></nobr>/opt) and then use 'checkinstall' to create an rpm. I then use 'rpm -U' to upgrade the installed package. In this way I keep my rpm database up to date and I can keep my eye on my own compiled stuff in<nobr> <wbr></nobr>/usr/local.

I use a similar trick with the KDE Konstruct facility. The entire KDE package set is compiled to go into<nobr> <wbr></nobr>/opt/<kde-version>, and by setting the global environment variables for KDEDIRS, I can move from one version of KDE to the next without trouble. The previous version is always available if needed.

#

That's fine, although I wouldn't do it. (But please don't distribute such RPM:s. checkinstall is a hack that shouldn't be used for serious stuff.)

#

USE GENTOO!

Really, most of these problems exist because of RPM based distros that feel the need to 'lead' in some way (like deviating from FHS standards which I totally agree with the author on). At least with Gentoo upgrading does not generally bring catastrophic results... At least, if you pay attention and know wtf you are doing.

Scruff

#

No versions. Never "upgrade" again.

#

I haven't hady any such problems with slackware....

slackware -- it only seems complicated because it is so simple

#

Gentoo!

#

yeah, hello Gentoo trolls. You've got a rolling development distro, whoopee. So's debian (sid) and Mandrake (cooker).

Back over here in the real world - I really like this idea. I enforce<nobr> <wbr></nobr>/usr/local separation on my system strictly and advise newbies to do the same as often as I can (I *hate* people who tell other people to install stuff in<nobr> <wbr></nobr>/usr). The idea of using<nobr> <wbr></nobr>/opt as a place for third-party RPMs is genius. It's probably more important on Fedora than most distros, since it relies so heavily on third party repositories - I run Mandrake, so the only non-MDK RPMs in my system are Java and RealPlayer. But it'd be a genuinely useful standard for everyone.

Of course, I guess it'd also be nice if the Fedora installer didn't touch non-Fedora packages, but maybe that's impossible for some reason. I'm not a Fedora guy.<nobr> <wbr></nobr>:)

#

BTW, I find it hilarious the amount of idiots who appear to have missed the point of the article entirely. It's dealing with third-party packages, people.

To my knowledge, neither Debian, Gentoo nor Mandrake will guarantee you a trouble-free update with third party packages. Especially if they've been written to install themselves into<nobr> <wbr></nobr>/usr. How *could* any distro possibly guarantee such a thing? If the main distro bumps glibc, or something, and Joe Third Party Package isn't updated, *it's going to break*. The author's suggestion, boiled down, is that third-party packages for any distribution should install themselves into<nobr> <wbr></nobr>/opt. I think this is a fine idea and it would have benefits for *any* distribution, Gentoo and Debian included. Feel free to disagree, but please stop using the subject as an excuse to troll for $MY_FAVOURITE_DISTRO.

#

As far as I know, with gentoo, certain packages have the possiblity of being installed along their old version number.
e.g. You can have both python 2.2. and 2.3 or something like that.

So far, in gentoo, no upgrade has ever hosed my system or made add on apps unusable.

There is only one thing to watch out for, and that is to be VERY careful when updating your config files.

There are tools to do this semi-automatically, but its easy for the noob to just select "update all configs" and have the update tool overwrite all of the updated configs with defaults.
As long as proper care is taken in this department, its all smooth sailing.

Im not trying to bash Fedora in any way. I'm just thinking, if your distro does something that annoys you so much. Perhaps its time to take a look at some alternatives.

#

Third party packages work fine with debian. All you have to do is use alien to change their native packaging to a<nobr> <wbr></nobr>.deb .


          If really strange library requirements are involved you can alien-ize those too. If the program is really of interest to many people, it will probably be packaged for debian anyhow, and can be found with google.

#

Fine. And does alien enforce third-party package separation (i.e., put them in<nobr> <wbr></nobr>/opt)- the idea this author is suggesting? No? Then it's not a solution to the problem. Sheesh, why is this so hard for people to see?

#

If its a<nobr> <wbr></nobr>.deb and will be packaged with everything else, then it does solve the problem yes. The author's gripe was about difficulty upgrading. He went on to say that he thinks its because they should be in<nobr> <wbr></nobr>/opt but thats not his main point.

#

There is no need to put it under<nobr> <wbr></nobr>/opt. Once it is under control of the debian packaging system, you can back it out using dpkg, apt-get, synaptic, gnome-apt or whatever package interface yanks your chain.

#

The spirit of the FHS is to separate the OS from third party packages, for easier maintenance. But with RPM:s you don't need to do that. Really. You don't.

But it is still useful to separate RPM installations in<nobr> <wbr></nobr>/usr from other types of installations in<nobr> <wbr></nobr>/usr/local. And RH recommends that. All in the spirit of the FHS.

Think of it like this: RPM is the OS, in the FHS sense. If it's an RPM, it goes in<nobr> <wbr></nobr>/usr. If it's not an RPM, it's not in the OS and should go in<nobr> <wbr></nobr>/usr/local or<nobr> <wbr></nobr>/opt.

So all you RH suxxors dweebs can go home now.

#

Like the others said, in Debian these problems just don't exist. I don't have to worry about anything bad... Debian stable upgrades are guaranteed to not break anything. Debian testing upgrades break something once for a few months, but it's never anything serious.

#

Being a (very) longtime SuSE user I used to share your "fear" of upgrading to a newer version of the current distribution. I have always experienced the biggest problems with upgrading KDE and sometimes with kernels (2.2.x -> 2.4, 2.4.x->2.6).

With upgrading KDE I have frequently burnt my fingers to the extent that though I have been able to continue working, various parts of the new KDE was sort of screwed up and messy. Only to be totally rectified by a total re-install of the newest official release.

Some 3 months ago I took an old PIII, 900MHz, 1.5GB RAM, 80GB disk, Woodoo3, Soundblaster PCI, CD writer, a Belkin Bluetooth dongle and installed Debian 3.1 from scratch, and as the only OS on the box.

I installed a minimum system from one bootable CD, quickly changed install parameters to unstable and installed a full-blown system via the internet (4 Mbit ADSL).
All hardware was immediately recognized and enabled.

Because this was a playground I have installed tons of apps, development environments and games.
I am also adventurous enough to use the 2.6.9 kernel (downloaded and compiled from source, from the debian website). I immediately ditched lilo and installed grub as well.

Using apt-get to upgrade the system every 2-3 days I have stil to experience problems as a result of upgrades! It simply works like a dream.

In terms of moving from SuSE to debian I have spent a reasonble amount of time familiarizing myself with the debian boot process and the layout of the file system which in both cases are rather different from the SuSE approach.
Actually the SuSE approach has always been the cause of most of my own upgrade problems in the past. SuSE frequently doesn't provide new technologies as upgrades to older (or the current) distributions as they reserve those upgrades for the upcoming release. Therefore you have to compile and install the "original" packages which are almost allways assuming different install- and config locations as well as startup- and logging procedures. This makes it a pain in the butt to upgrade a number of packages including KDE.

By now I have migrated both my laptop and workstation to debian (from SuSE) and the server will follow soon (though not with the unstable version).

My only prior experience with debian was about 4-5 years ago. At that time I found it to be a disaster to install. Being an application/purpose oriented person that actually need to use the computer to perform essential work (frequently yesterday rather than today), I then discarded debian as a "geek toy".
Those days are long gone. Installing debian today is no more difficult than installing any other distribution.

The fact that it can be seamlessly updated/upgraded is actually MUCH better than the SuSE proposition especially for a fully loaded workstation / laptop setup. For the less sophisticated server application, a bare minimum debian based LAMP/samba setup is much less bloated and much faster than a standard SuSE install and in my case will not require bleeding edge s/w releases to do the job.

Try setting up debian test system and see for yourself!

#

Fedora is really a testbed distro. Something to play around with on a spare PC or in VMware.

You can use it 'for real' of course, but only if you don't mind constantly playing around with your system. Red Hat will undoubtedly put experimental stuff in here and change things around regularly in order to 'get it right' for future Enterprise releases.

Gentoo and Debian have both largely solved the upgrade problems. Other distros have longer release cycles (a fresh install every 2-3 years isn't so bad).

FYI my<nobr> <wbr></nobr>/opt looks like this:

OpenOffice.org1.1.0
RealPlayer9
bin
blackdown-jdk-1.4.1
netscape
opera
vmware

Anyway, it's good to advocate FHS and explain to people a bit about what belongs where, but perhaps not in this context.

#

Save yourself and switch to gentoo or debian (or maybe you could give free BSD a go) you won't never EVER have to rebuild a totally new system.<nobr> <wbr></nobr>...my upgrade...
emerge sync
emerge world<nobr> <wbr></nobr>...coffe<nobr> <wbr></nobr>...sometimes triple coffee<nobr> <wbr></nobr>;)<nobr> <wbr></nobr>...take a look at config files
done !!!

#

Ask in the Fedora users list, file bugs or refrain from writing articles about how things suck.

Fedora is 100% free software and patent-problem-free. That means no DVD player, no DivX player, no RealPlayer, no MP3 player. That's just the way it is. Get over it.

Installing them is a breeze. It works. If you do it the right way. It's not easy to know what the right way is, but that's because Fedora is a very new distribution. It'll get better.

#

I've been using Red Hat Linux since 1997 and I've seen the RPM dependency hell up close a number of times (although I'm fairly well skilled at making RPMs, so I've always managed to dig myself out of any tricky RPM situations, but I appreciate that many users couldn't do that). When RH announced that Fedora would be replacing RHLinux as their public, free version and that it would integrate the third party packaging work done by fedora.us and others I was very hopeful that this would finally provide RedHat with a system more like Debian in terms of number of packages available, but with third party maintainers taking the bulk of the work - to me this seemed like an ideal solution, less of the politics of Debian and more great software for every Fedora user.
Sadly it didn't work out that way, all of the third party repositories (fedora.us, dag, freshrpms, newrpms, atrpms, etc) are still third party repositories and better yet they aren't all compatible and some of them contain old packages from the other ones to satisfy dependencies.
This is simply unacceptable. In FC2 yum was so pathetically slow that with several of the other repositories added on my 2ghz system it would take *minutes* to calculate dependencies for even the simplest of package installations/upgrades, where apt-get would always figure it out for more repositories in far less time. Ok they mostly fixed this for FC3, but the other repositories are *still* not integrated.
Until they are, I can't see myself using Fedora for anything but a simple desktop that doesn't need much/any third party software installed.
Flip over to Ubuntu and you see a very different picture. They have three repositories, main, universe and multiverse which covers the packages supported by the Ubuntu developers (main), packages imported from Debian (universe) and various other things that are legally questionable for including in the base distro (multiverse).
They have a much friendlier attitude to getting extra software in too - universe can be made to import any package from Debian sid, so requests for software from there can be fulfulled at 24 hour intervals when they sync with Debian, or third party groups can ask to include their packages and agree to maintain them.
To my mind this is *the* way to go forward with distros, you have to have a repository somewhere that third parties can place their packages - that way if a vendor/coder sees a potential market on your distro, *they* can come to *you* with a package instead of it being the other way around.
I desperately hope that Red Hat sorts this out quickly, but from what I can tell they are focussed on getting new stuff into Fedora so it can feed into Enterprise. As a side note I was very surprised to see Enterprise 4 follow on so quickly from FC3, since it contains many of the new and not especially mature technologies that FC3 should be providing an additional 6 months testing of.
So, in summation, try Ubuntu, it's very nice<nobr> <wbr></nobr>:)

#

The problem is that fedora.us failed to establish itself as THE extra repo. They never cared about being compatible with the already established repos like FreshRPMs and Dag, so users had to choose between either fedora.us+livna or freshrpms et al. At the same time, conflicting methods and goals made sure that the bulk of the freshrpms et al packages were never ported to fedora.us.

This will probably be fixed now with the new official Fedora Extras for Fedora Core 3.

#

Others suggested FreeBSD, OpenBSD and NetBSD are equally simple...

#

Linux should be about upgradeable without having to massage your<nobr> <wbr></nobr>.cshrc,<nobr> <wbr></nobr>.bashrc Xorg or XFree86.config, httpd.conf etc, etc, etc...

Gentoo is the only Linux distribution that understands this. I say this even as I use Slackware 10.0 which is not really upgradeable from 9.0.

I too came from RedHat where I started out with 4.3 I got from my first Linux book Discover Linux.

I felt that as I moved from 4.3 to 5.1, 6.0 skipped 6.1 to 6.2 then to 7.0, 7.3, 8.0 and finally 9.0 that RedHat was getting the upgrade thing down and I was hooked,a financial and vocal supporter of RedHat. Then it happened, corporations became the focus of RedHat and I as you became a nuisance to RedHat. Heck and I never made a support call to them either I just bought, installed, learned, used and profited from RedHat, Go figure.

So I decided I had learned Linux good enough to go with most nonintuitive Linux distribution available Slackware 9.0. All because I wanted to really understand the configuration of Linux and its supporting applications by being forced into it. I did so at the expense of upgradeablity. With my upgrade to Slackware 10.0 I had to do a reinstall.
I was backed up so no big deal. Well I asked for it and I personally am not upset because I do get to reinforce my configuration skills and learn a new X interface Xorg which I must say I do like better than XFree86. But still it is not Upgradeable as the old RedHat 9.0 was.

The path RedHat took after 9.0 was in the same non-upgradeable direction. Obviously this was done to force corporate customers to seek services from RedHat. In order to get the new RedHat De-jour installed and supported of course. Fedora is part of the same philosophy. Not that I blame RedHat for wanting to make a very large profit who does not like money. I believe RedHat embraced IBM in error adopting the IBM marketing and services approach to business.

I have watched IBM make one huge mistake after another since they invented the PC. Since the Acquisition of ROLM corporation dumping a billion dollars into software and product development and then selling off the unit to Siemens at a loss, to this latest act of self amputation with the pc unit.

The gist of what I am saying here is that in the long run RedHat will do to its corporate customers what it did to us before because they have quite simply lost the spirit of Linux in favor of immediate profits. To make a Linux distribution upgradeable means less profit in services. So RedHat has to make each release completely incompatible with the present one to survive. The best way to do that is to make the testbed non upgradeable to get the future customers used to the fact that to move into a future release of Linux it is going to cost you bling bling!

That in my opinion is fundamentally broken.

#

replace "every Linux user knows" with "every Redhat/Fedora Linux user knows"

as there are many Linux users who know not of what you speak.

#

The article is well presented and constuctively critical points are made. Save the grammatical never say "everyone" thing, it's clear and to the point that having an "only install" path for distributions is a huge bottleneck.

Most of us have experienced this(not everyone<nobr> <wbr></nobr>:), and some solutions are to use gentoo or compile time bsd's. And that may be a solution given all the randomness of packages. But<nobr> <wbr></nobr>.. But, for the user that needs/wants to install an OS that they can simply use for server-length time periods- this is not a solution.

We don't have a solution yet. And that's the author's point I think. It is something to consider for the future of Linux userland. Good article and something I need to start thinking about myself.

#

If you really want "an OS that they can simply use for server-length time periods," a project like Fedora isn't the best choice.

#

I agree. What is the best choice for user desktops that can last as long as the hardware? That's the question.

#

hey! just use debian! Problem solved.

#

I agree!

#

This article brings to the surface some interesting issues.

But still we get the same old answers:

'Why don't you change to this distro?' yeah thanks, I'll just download the disk images/bootstrap image and install yet another distro, great idea.

or

'Well it's obviously a problem with `{insert package mgmt tool name here}, why don't you change to '{insert distribution name here}' instead?' See above, more of the same garbage.

or

'I had a bad experience once 5 years ago with this distribution and would never use it again' Mmmm, and it couldn't change in 5 years could it?

or my favorite

'Maybe you're using the wrong distro' Oh really, and you know what I need of a distro do you?

Bottom line, whatever the problem, the best we seem to be able to come up with is the same old 'change to the distribution I use cos it's great'.

That doesn't fix anything, it's worse than telling a user to just reboot when a problem occurs (a la windows). Look at the replies to this article, the most active thread isn't a discussion of the possible resolution of the problem but a load of garbage about how wonderful Debian and Mandrake are (no offence to both distros, just the users posting off-topic rubbish, installing another distro is not a fix)

I thought the community was interested in finding quality solutions to problems, this looks to me like yet another case of 'my distro's better than yours' great, just what we needed.

#

Actually, I believe you are wrong. I think the reason people are saying "switch to another distro" is because they believe that the problem the author is describing does not exist in these distros. In that case "switch to another distro" would really solve the problem. And if you don't want (cannot) switch, then maybe you can help implement a sustem in your distro that is similar to the systems that work for the other distros.

Basically, what people are saying is "this problem already has a solution, and it has been implemented in<nobr> <wbr></nobr>..."

Is it true? Frankly, I don't know. I must admit I simply don't understand what the author of the article is talking about. Maybe it is because I use one of the distributions that supposedly solve this problem. Let me describe what I think about this:

1) Third party packages that are handled by your packaging system should go to<nobr> <wbr></nobr>/usr - there should be no difference between and official package and a third party package. It shouldn't matter which repository did the package come from. As long as it is well packaged and specify all its dependencies well, it is equal to any other package. If it doesn't, then it's a crappy package and should be thrown away.

2) Stuff you compile yourself should go to<nobr> <wbr></nobr>/usr/local

3) third party binaries that are not handled by your package system should go to<nobr> <wbr></nobr>/user/local if they are just simple small packages, or to<nobr> <wbr></nobr>/opt for larger more complex packages, anything that could make a mess in<nobr> <wbr></nobr>/usr/local.

Now let's see what happens if you upgrade:

First let's look at a third party package that is installed by your packaging system. In the best case, the repository the package came from already contains a new version of the package (in debian world, this is usually the case). In this case, you won't even notice. The package will get seamlesly upgraded with the rest of your system.
If this is not the case, your system will examine the dependencies of the package and decide if they still can be met after the upgrade. It could mean keeping some old versions of libraries around in addition to the new ones. If it is possible, the package will be kept without changes. If there is a problem (some of the dependencies has to be upgraded because of a conflict), the package will be removed. That is undesirable, but I don't see how puting the package in different location can possibly fix the problem. In that case there are only two fixes: write the authors of the package ask them to repackage it for the new version of your distro (they really should do that), or compile the software from source.

If the software is in<nobr> <wbr></nobr>/opt or<nobr> <wbr></nobr>/usr/local, your package managment will not touch it. Therefore it will not be directly affected by the upgrade. Most likely what will happen is some of your libraries will get upgraded, and the software may refuse to run. This will probably not be an issue for large packages in<nobr> <wbr></nobr>/opt, because they usually pack their own versions of libraries, or are statically linked, so as long as you don't upgrade glibc to an incompatible version, you should be ok. The stuff in<nobr> <wbr></nobr>/usr/local may break. But again, in many cases your distro will let you install old libraries alongside the new ones (official debian repositories have section called oldlibs for exactly that purpose). If you cannot do that, you will have to recompile. If you compiled from source at the first place, then recompile should not be a problem. I also found that most of the time, new version of my distro actually package most of the programs I installed from source, so I just need to uninstall the programs and use the packaged version. I do less and less compiling from source every year. I used to compile pretty much everything, lately I have just few things in<nobr> <wbr></nobr>/usr/local, and most of them are not that important anyway.

So it pretty much boils down to breaking third party binary packages in<nobr> <wbr></nobr>/opt when you upgrade glibc. Is that what the article was about?

#

Actually, I believe you are wrong. I think the reason people are saying "switch to another distro" is because they believe that the problem the author is describing does not exist in these distros. In that case "switch to another distro" would really solve the problem.
Sorry, don't agree. Changing distro does not resolve the problem, it merely circumvents it (and you have to admit it's a pretty large circumvention!). The problem still exists, you just don't suffer it because it is not an issue in your 'new' distro.
Now, if you are a 'I'm alright Jack, stuff you' person well fair enough, you move to a new distro and everything is wonderfull. It just doesn't strike me as being particularly 'community' minded. Remembering in this case specifically that we are talking about a supposed 'community' distro.
It's just that recently I've seen a number of problems discussed on mailing lists etc and in each case the 'resolution' offered is nothing of the sort, it is a circumvention.
And if you don't want (cannot) switch, then maybe you can help implement a sustem in your distro that is similar to the systems that work for the other distros
That's what I was talking about!

#

Yes, I see your point. I guess I was talking about "solving the problem for one particular person" rather than solving the problem for the distro.

There are actually people working on the solution, apt-rmp project for example. It seems to me that what is still missing are package repositories. Apt is only one side of the coin, the wonderful debian repositories, both official and unofficial, are necessary part of the solution too, as well as the very well defined debian versioning scheme.

Maybe one of the reasons lot of people reacted the way they did was that the article wasn't particularly well written. It talked about "every linux user" and linux in general. Also, the solution proposed in the article was, in my opinion, wrong. Letting the packaging system touch<nobr> <wbr></nobr>/usr/local and<nobr> <wbr></nobr>/opt does not really solve anything, and has a potential to create even more mess. Linux upgrades do have occasional problems, for example the glibc upgrade problem was mentioned several times in the discussion, but the author of the article, IMHO, did not really know what he was talking about.

#

I just <A HREF="http://apipes.blogspot.com/" title="blogspot.com">blogged</a blogspot.com> my recent experiences with the same thing.

In my case, the same issues recently caused me to migrate from all Linux distributions to FreeBsd. Even without the upgrade headaches (I've switched to doing to complete installations every time now), each release of Fedora Core has broken something new on my system.

#

I've just read your blog entry and you've completely missed my point.
That you have had a series of bad experiences with Fedora Core is without question.

But that has nothing to do with what I am talking about.

The original article highlighted problems as detailed by the author pertaining to os upgrades (in this case Fedora Core) and more specifically third party packages mangled/removed during the aforementioned upgrade and hence, boat-loads of hassle and work you didn't want/need. The author then provides his view of the problem (FHS (non)compliance, issues with third party package repositories etc) before proposing a solution.

This is a package management/distro management issue. Nothing else.

It has to be said that the problems highlighted here, and in other articles of the same nature shouldn't come as a suprise when you consider the circumstances (with the benefit of hindsight of course):

A new Fedora Core distribution hits the streets every 6 months. It must be a real problem for independant packagers to keep up with this rate of change. Remember, these people are doing this off their own bat alongside working/studying, or whatever else. Their time is very much finite and, I would imaging, decreasing when you consider that some of them (eg, Dag Wieers) are providing packages for up to 9 different flavours of RedHat/Fedora.

Another problem as mentioned in the original article,

'But the repositories and the distros each act like they live in separate worlds, and when upgrade time comes, it's the user who is inconvenienced.'

is also mentioned by ESR in his Fedora Multimedia Installation Howto. This is another crucial issue with regard to this problem. If we enter into a world of package conflicts, nothing but bad is going to happen.

When we add FHS non-compliance by the distro (I don't like that) we can see the potential for getting ourselves into a rather grisly mess.

The author's proposal goes some way to resolving the problem. But the situation almost demands another change.
A unified third-party package repository.
At this point I will invoke my get-out clause and return to the 'My distro is better than your distro' argument. We can learn from Debian. Debian Non-Free seems to me to be the way to go. A unified repository for packages of a 'questionable' nature with regard to license/patent/whatever else, otherwise refered to by ESR as

'Damned Things that Fedora Core won't carry'

. The independant packagers do a fantastic job as it is, if they actually pooled their respective resources the results could be, in my view, well worth the effort. Particularly in the long term. This is a project that is supposedly under way, under the catchy title of RPMForge.

#

Forgot to mention that the RPMForge project does not as yet include all the third-party repositories. For it too really work, RPMForge needs all the repositories on-board.

I have to say that personally I've had good experiences with all the Fedora Core releases. Sure, I've had some problems, but personally no real show-stoppers. I installed FC3 about a week after release and save some nonsense with udev and NVidia's binary drivers that cost me about 30 minutes and something else I can't remember it's worked fine. Granted I'm not the most complicated user in the world (that's not what I want) but it's worked like a charm. Even with SELinux enabled.

I thought computers where supposed to work the same for everyone ?!!

Ok, I shall now lie down in a darkened room. I just read the reply before this. God the formatting, or lack of is a disgrace, apologies.

Transmission Ends

#

Don't let the gentoo dorks read the article or they'll get their panties in a knot since daily upgrades are their bread and butter. When touting the virtues of gentoo invariably dependency-hell, and how much rpms suck is right after the "my machine is so much faster, since I spent a week compiling everything" response.

Personally, I upgrade when I see a package has security flaws, or I like the new features of an updated version, not "I update just because there is a new version out."

#

Personally, I upgrade when I see a package has security flaws, or I like the new features of an updated version, not "I update just because there is a new version out."

But that's precisely the point, how long will you do that before your current installation base completely out-dated and you are required to update something newer?

I'm not sure what is meant by "bread and butter", but yes, the incremental upgrades do have downsides, but I will gladly take the option of being able to exactly pinpoint what broke what with small updates gradually than a giant Cluster-F when everything is upgraded at once.

It's a personal preference call, really.

#

All of your problems are solved with debian!
Or gentoo!
Or Arch/Slackware/etc...

Fedora guy 1: I don't have any problems upgrading.
Fedora guy 2: me neither.

  [...]
Fedora get n: me neither.

So... looks like we are a pretty happy bunch.
Now SHUT UP ALREADY!
Sheez...

#

no need for any of that crap... system upgrades through YUM are seemless! - meaning, non destructive to non FC3 packages floating around anywhere... how?... because handles each package RPM headers seaparately - only following for dependancies... thus only the changes (or newer) stuff from FC3 is installed... that leaves your mplayer intact.

So whats the fuss...?
"yum upgrade" already!

did I mention the tedious work of adding the FC3 repos to yum.conf... do that too.
-sp

#

I have yet to see an operating system for which an upgrade without a fresh install is superior to a fresh install. Free software or proprietary, I've never come across an OS where I can honestly tell a client that it's okay to not fresh install.

But under some OSes (and with some programs), I can minimize the hassle by mounting user directories without recreating everything. For instance, under Fedora Core 3 GNU/Linux it was easy for me to mount a drive with homedirs on it then move all the old files for each user from the users over to their new homedir in such a way where the user can restore what they wish (copy over dot files, directories filled with e-mail, etc.) or make a new configuration (run the program). Restoring my previous Mozilla-based configurations are quite easy, as they are all flat files in certain directories. My biggest hassle here has been the gconf hierarchy of settings, but even this is hardly a showstopper which keeps me from switching from Core 2 to Core 3.

I wish standards would be obeyed too, and I wish there were a single update/update-notification program I could use (yum, up2date, smart, and apt all have their strengths and weaknesses) so that I could use that to update installed programs. But in time that will probably come.

With<nobr> <wbr></nobr>/home on its own partition, I can wipe out<nobr> <wbr></nobr>/boot,<nobr> <wbr></nobr>/, and swap.<nobr> <wbr></nobr>/var/log I can continue to build on or wipe out and start again. No worries for me, as I keep backups (something all users should be doing, something GNU/Linux systems should make it far easier to do without thinking about it much).

J.B. Nicholson-Owens (jbn@forestfield.org)

#