Debian Upgrade May Cause Serious Breakage

daria42 writes "Debian developer Bill Allombert has e-mailed the Debian community saying he estimates about 30% of users upgrading from Debian Woody to Sarge will suffer 'serious breakage'. Allombert says the upgrade process suffers from a number of bugs reported before the release went live several days ago. Chief among the problems, he said, were cyclic dependencies and the fact that software installation tool apt depended heavily on the changing C++ libraries. Allombert wants developers to test the upgrade cycle continuously during development and not just during the freeze period just before release."

Comments

Evidence of problems with packaging systems

[AKAImBatman]

Chief among the problems, he said, were cyclic dependencies and the fact that software installation tool apt depended heavily on the changing C++ libraries.

Let this be a lesson to those of you who claimed that "APT is unbreakable." There's no such thing as an unbreakable technology. There is however, such a thing as a robust technology that resists failure. As packaging systems go, APT is fairly good. However, my belief is that packaging systems are inherently flawed.

What you want in an OS, is a method for determining the precise core upon which you can base your applications on. Such a core would effectively be an immutable set of system APIs that cannot be changed. The upshot to this situation is that the given system is verifyable. i.e. I can have a script go through and ensure that everything that should exist does exist. From that information, I can then do a delta to find out what exists that shouldn't exist.

This is in direct opposition to a packaging system that builds an OS out of inter-dependent components. The problem with such a strategy is that using inter-dependent components only works if you're building from scratch. As anyone who has managed a version control system can tell you, things get extremely complicated (and tend to require manual intervention) as soon as files start branching. The same thing happens in packaging systems as soon as you start doing upgrades to individual components. Soon you find yourself with a mess of mismatched dependencies which require constant manual intervention to solve. Not a good situation.

In the case of a defined core, you can simply wipe out the old core and replace it with the new one. As long as testing has been done to ensure that the new components are still backward compatible with old software, everything should work fine after the upgrade.

Food for thought, anyway. To the Debian team: Thanks for the new release! Even if there are some growing pains, it's still nice to see you back in the game. :-)

Re:Evidence of problems with packaging systems

[Tharkban]

Give it a rest.

The Linux Standard Base is dead.

There is too much freedom for even the distributions to make cores effectively. Debian doesn't develop the software, they package it. They have no direct control over compatibility issues between versions in their software. This makes their job a whole lot harder than in commercial OS's where one entity controls both the core software and the packaging.

They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.

Re:Evidence of problems with packaging systems

[EnronHaliburton2004]

The upshot to this situation is that the given system is verifyable. i.e. I can have a script go through and ensure that everything that should exist does exist.

This is probably one of my biggest gripes about Linux.

The larger Unix OS's like Solaris & AIX have 'patchlevels' which seem to meet some of your criteria. To upgrade your the OS, you install a patchlevel on top of your existing OS. It's easy to verify all components of the OS.

You know exactly what the OS contains--- "Solaris 5.9 build 100041-23" contains Kernel version X.Y.Z, C compiler X.Y.Z, C libraries X.Y.Z.

Want to see the patchlevel? Simply type 'uname -a'. Want to check the signatures of all binary software on the system or check for missing or modified files? It's easy to do with a few commandline utilities.

With Linux it's the opposite. You need to check the version of each individual package. You have an md5 string to compare against the .deb, .rpm or .tar.gz file, but how can you verify all components in the system?

Re:Evidence of problems with packaging systems

[Lexicon]

This is exactly what Debian does within a stable release; only package updates that maintain the api are allowed, and is why people who just want to use the system really need to stay with the stable release and not use testing for critical day-to-day tasks.

Especially with the huge time between releases, I do not believe it is realistic to expect upgrades from one stable release to another to work cleanly. With any set of software it is generally much safer to do a clean install, then migrate your configuration over to the new setup than to risk your data and applications trying a major version upgrade. I don't think that this is a specific package-related issue, it is going to happen any time you do an api-changing upgrade.

Your api examining idea is interesting, but isn't specific to a package system or not having a package system; it could be implemented by having the package system check those apis for each dependency. Even then, though, there's not going to be a good way to see if those apis, even if they appear the same, have subtle intent differences which are not going to be easy to detect.

At any rate, I recommend clean installs and not upgrades for any major update of any operating system, unless it is a test or non-critical machine.

Re:Evidence of problems with packaging systems

[listen]

You again ;-)

Take a look at this Conary system. It has some interesting ideas that could certainly help in this kind of situation : especially transactions for upgrades. If a bit fails, the whole upgrade rolls back, and you can even rollback completed transactions.

I like this idea better than choosing some arbitrary core of code to upgrade as a massive lump, and statically linking hundreds of copies of anything not in the core into the separate apps. As to your verifiability detecting script, I see no reason this can not be done for a packaging system. And before you go on about corrupt databases, please remind yourself what a filesystem is: thats right, a corruptable database.

I will agree with you on compatibility: people should stop breaking ABI. I'm looking at you, Freetype...

Re:Evidence of problems with packaging systems

[ArsonSmith]

rpm -qa (rpm based distros)
dpkg -l (deb based distros)

Thank you, next question.

Re:Evidence of problems with packaging systems

[AKAImBatman]

They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.

I agree wholeheartedly. I'm not attempting to "diss" the Debian distro or its maintainers. I'm only pointing out that the packaging system is beginning to strain under the pressure of so many packages. The complexity of the package system is quickly becoming too difficult to maintain. Especially since the packaging system mixes the core system APIS with the user applications. (Always a recipe for trouble.) Thus it is time to start thinking about something new.

The Linux Standard Base is dead.

The LSB was always about the "least common denominator" and not about "the most usable configuration". For what it was, it wasn't too bad. But a real standard at this point would have to define a lot more libraries, although perhaps at more of a library version level than trying to force the individual APIs.

With that in mind, I don't think that such a standard should be attempted across all distros. For one, that would limit their ability to be different and provide new competitive services. For another, it tends to be better to allow a few different standards to compete before you attempt to pick one or two out of the fold. For example, there used to be many standards for Linus base distros. Now all distros tend to fork from either RedHat or Debian. Standards thus emerged.

The same thing should happen today. We should see different distros attempt differing solutions to the issue and see which ones work best. Symphony is certainly one of the most interesting, but mostly because it's the first attempt to break away from the current designs that Linux is stuck in. :-)

Re:Evidence of problems with packaging systems

[KiloByte]

The only issue is: if you don't read the freaking release notes, you will have problems. The apt in Woody is broken. The release notes say that you need to update it first, to let it handle circular dependencies.
The only fault of Debian is not putting this in a bold enough font.

Also, this breakage gives us a yet another reason to bash C++ as a poor excuse for a language :p

Re:Evidence of problems with packaging systems

[swillden]

I do not believe it is realistic to expect upgrades from one stable release to another to work cleanly.

Then Debian has been meeting unrealistic expectations for many years now.

I've upgraded cleanly from slink to potato to woody to sarge. Despite what this guy says, this one seems to work just fine as well. AFAICT, the only difference between this and previous upgrades is that this one has an extra step.

Re:Evidence of problems with packaging systems

[MuMart]

Has it not occurred to you that Debian stable is exactly this "immutable set of system APIS" you are advocating?

The purpose of the packaging system is to ensure the system is in a verifiable state and that the software can assume the existance of a specific set of APIs.

Your suggestion that software should include all of its dependencies is in direct opposition to the open source process. If code is shared it recieves testing by all the software that depends on it, and flaws are far less likely to go unpatched.

For a taste of the dangers of not sharing code, witness the recent security holes in the zlib and Windows GDI libraries.

Re:Evidence of problems with packaging systems

[IllForgetMyNickSoonA]

What you just said is in not in the least the answer to his question.

The commands above just list the installed packages, which may or may not include the version number in their name. Usefull, no question about that, but something completely different from what the parent asked for.

Re:Evidence of problems with packaging systems

[Feyr]

out of ~15 systems i've upgraded to sarge in the last two days, i've had major troubles with 3 of them, and expect the same on two more.

one of these 5 systems i tried to upgrade from apache to apache2 (non-critical system, so i could afford the downtime), another was a former production system that we pulled from the cluster to test the upgrade.

it would be a fallacy to expect a completly seamless upgrade for any system with major configurations that's been in use for more than a few years. what with the backports (because sometimes you just can't avoid em), packages installed from source (.tar.gz, not .debs), script s scattered all over (because you just know different admins like them in different places) and hardcoded paths.

despite all these caveats, it's still pretty easy to upgrade, so long as you know your systems. just don't do it outside a maintenance window :)

Re:Evidence of problems with packaging systems

[cowbutt]

With Linux it's the opposite. You need to check the version of each individual package. You have an md5 string to compare against the .deb, .rpm or .tar.gz file, but how can you verify all components in the system?

rpm --verify -a

and to check you've got all the current updates:

yum check-update

This is on FC3, but both yum and rpm have been around for quite some time.

Re:Evidence of problems with packaging systems

[hackstraw]

However, my belief is that packaging systems are inherently flawed.

Yeah, it sucks to drag and drop an application to anywhere on my harddrive and have it work.

I don't know guys. Using OS X for a while really makes other OSes seem very, very primitive. Most all applications can just be DNDed or run out of a disc image and they work. "Applications" in OS X are specially organized directories and all of the libraries and/or helper applications (I've even seen perl scripts inside of an application) are contained in one place.

Best method of installing software that I've ever come across, hands down.

Re:Evidence of problems with packaging systems

[timeOday]

What you want in an OS, is a method for determining the precise core upon which you can base your applications on. Such a core would effectively be an immutable set of system APIs that cannot be changed. The upshot to this situation is that the given system is verifyable. i.e. I can have a script go through and ensure that everything that should exist does exist. From that information, I can then do a delta to find out what exists that shouldn't exist.

This amounts to wishing the problem away. Sure, it would be nice to have a good implementation of a complete specification for everything, with no version incompatibilities. It would be nice if money grew on trees also.

The point is, the world constantly changes and progresses. You cannot isolate a large system of interest from external developments, so stop trying. It would be nice if all package installations went smoothly, but not nice enough to justify using Gnome 0.6 for all eternity.

For small, safety-critical systems, where it makes sense to have lots of feature and version freezes, that's exactly what people already do.

Re:Evidence of problems with packaging systems

[Qzukk]

I mean, come on, there were 10,000 pairs of eyes looking at the source code and fixing bugs before it was released, right?

Right. And they fixed the bug, and told everyone that apt was broken and to upgrade to the fixed apt before attempting to upgrade to sarge.

And nobody listened.

Re:Evidence of problems with packaging systems

[EnronHaliburton2004]

Thanks genius, but that doesn't answer any of my questions.

Here's another one of my top gripes about Linux. I ask a question, and I get a stupid answer from dumb snot who clearly doesn't understand the question.

Listing the packages is easy. But your solution doesn't deal with patchlevels at all, or show how to verify the installed packges in a patchlevel, or check to see if any files are missing from the packages, etc. You can do some of this stuff with individual packages, but not with clusters of patches.

I can do that in the big Unixes, but the concept seems foreign to Linux users. It's sad, really.

Re:Evidence of problems with packaging systems

[Tony Hoyle]

You can't put libraries inside an OSX app without ugly hacks manually updating LD_LIBRARY_PATH, and if you have multiple executables to run that isn't going to work.. for proper installation they need to go in /usr/lib or /usr/local/lib, with your binary in /usr/bin just like any other applicaiton/

The idea of using directories as apps was done years ago in with RiscOS. It only works for very simple applications with one entrypoint, but if you have a larger application it just doesn't work to do that - you need a proper installer.

That's why if you install most Apple programs they don't in fact use the drag/drop metaphor at all - they install to fixed places on the hard disk like any other installer.

Re:Evidence of problems with packaging systems

[Seumas]

How can anyone be surprised by this?

Last time I did a dist-upgrade (it's been at least a couple years), it screwed my perl installation up. And as anyone who runs Debian knows, it's pretty much useless without a working perl installation.

It took me many hours to recover from the problem. And because of that, I don't intend to dist-upgrade this time at all. If I ever get around to upgrading, I'll spend a couple thousand dollars to replicate my dual AMD 1U rackmount, install everything on it with the current Debian distro and then stuff the drives into the old machine that I've been running for years.

I love Debian. I've just had some really awful apt-get experiences. Especially when it comes to dist-upgrades.

Re:Evidence of problems with packaging systems

[EnronHaliburton2004]

and to check you've got all the current updates:

yum check-update

Good point, and Yum is a great tool. But doesn't that only compare the new updates in the repository?

What if I don't want the latest & greatest files in the respository? Can I check all packages against a particular OS level? On Solaris, I can say "Check that I have all packages released in Solaris x.y.z patch 5, which was released on June 2, 2005"? Can I do that with Yum?

I frequently don't want the newest versions of the packages.

Re:Evidence of problems with packaging systems

[AKAImBatman]

The point is, the world constantly changes and progresses. You cannot isolate a large system of interest from external developments, so stop trying. It would be nice if all package installations went smoothly, but not nice enough to justify using Gnome 0.6 for all eternity.

Now you're just being silly. Is OS X isolated from outside developments? No. Because the entire system core moves as one large piece. The applications are more dynamic, but they always are targetted directly at a minimum system level. This is different from Linux where Debian Woody can mean different things to different people depending on how many updates they've done from the repository. One system could be GLib 2.1, while another could be GLib 2.5*. An application may then refuse to install either because you don't have a new enough version of GLib, or because your version is too new!

If a system core moves at as all or nothing standard, then this issue doesn't exist. If a program needs an API that isn't included in the core, it can bundle it. The user's life is easier, and the system maintainer's lives are easier.

* Made up version numbers. I don't remember what the real ones are.

Re:Evidence of problems with packaging systems

[flithm]

That was a good post, until you decided to troll.

C++ may be a poor excuse for a language, but changing C++ libraries are not one of the reasons. That fault lies with the gcc team, and even then it's not really a fault.

It would have been much more accurate to say that the g++ portion of the Gnu compiler collection is driven by people who are poor excuses for developers, but that's another story entirely.

And just so you know, some of the greatest languages ever designed suffer from similar (or greater) problems. Objective-C has terrible cross platform, cross-architecture, and cross-version compile and run time problems. Even the Gnu C library itself isn't necessarily compatible from version to version.

Most distributions have to keep a number of glibcs around just to satisfy dependencies.

All in all, the bottom line is that the problem is with the Debian team, not with the people who didn't read release notes, or with C++, or with anything else.

If all they had to do was upgrade, the installer / updater should have done that automatically... especially since the problem was known to be a problem prior to release!

Seriously, they wait how many years to release, and when they do a full one third of their install base is left with an unusable system?

Very very bad.

Re:Evidence of problems with packaging systems

[AKAImBatman]

You can't put libraries inside an OSX app without ugly hacks manually updating LD_LIBRARY_PATH, and if you have multiple executables to run that isn't going to work.. for proper installation they need to go in /usr/lib or /usr/local/lib, with your binary in /usr/bin just like any other applicaiton/

But you can statically link them. It's effectively the same result. A Linux system based on the AppFolder concept could easily fix this oversight if so desired.

if you have a larger application it just doesn't work to do that - you need a proper installer.

That's why if you install most Apple programs they don't in fact use the drag/drop metaphor at all - they install to fixed places on the hard disk like any other installer.

This is patent nonsense, and I wish that people would stop repeating it. I've used an OS X system for about two years now, and the only installers were for Unix command line components, "portable" Java installers, system updates, and that's about it. Pretty much ALL OS X apps come in an appfolder. The few that don't tend to just build an APP file anyway. Most of those were from earlier versions where the vendor wanted to pop up a EULA before allowing the software to be run. DMGs now support the ability to show a license on open, so this issue has mostly gone by-the-by.

Don't believe everything you read. It may be FUD. ;-)

Re:Evidence of problems with packaging systems

[AKAImBatman]

Please, try to be civil. Allowing the discussion to degrade to a flamewar won't help anyone.

Re:Evidence of problems with packaging systems

[runswithd6s]

They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.

I'm not sure what weed you're smoking, but Debian backports ALL of their security fixes from upstream software to the version packaged in stable. Really, consult the Debian Security FAQ for more details.

Re:Evidence of problems with packaging systems

[rpdillon]

I'm not really getting you on this one.

I think RHEL does the kind of thing you're asking for.

I think of the Linux world as split in two. There are distros that are fundamentally CD based - like Fedora core, RHEL, Xandros, SuSe, etc. The CD based distribution system lends itself to the kind of thing you're talking about: patchlevels, service packs, batch upgrades - it provides known checkpoints for your OS.

Then there are distros that are internet based - they use central repositories to manage software, and though they may come on a CD, it's really just a snapshot. Debian and Gentoo come to mind in this category. The idea of a central repository is antithetical to your notion of checkpoints and patchlevels. Everything is a moving target, even in Debian stable, testing and unstable.

All that said, I don't do a lot of server-level verify-my-whole-machine-with-md5 with any of my Linux boxes. I upgrade packages when I need to, either for new hardware or new features, and things generally work really well, and maybe on occasion some ebuild will break something and I have to go put out the fire. Of course, I use masked packages all over the place, so I expect that now and then (couple times a year). Maybe RHEL/CentOS would be more akin to your experiences with AIX and Solaris.

Re:Evidence of problems with packaging systems

[arkanes]

If all they had to do was upgrade, the installer / updater should have done that automatically

Don't know much about Debian, do you? Anyway, that is (precisely) what these release notes told you to do. Upgrade apt, then upgrade everything else. Very simple.

Re:Evidence of problems with packaging systems

[cowbutt]

What if I don't want the latest & greatest files in the respository?

Why would you want to run anything other than the latest and greatest security-fixed, stable and tested packages? Bearing in mind that if you're using dependent FOSS packages, they'll probably be rebuilt and repackages fairly quickly after any updates (if necessary). That only really leaves the case where you're running some closed application; if you are, you'll probably be running RHEL or similar, and RH will be communicating with the ISV. If the ISV can't get a new package built and validated in time for the official updates, that's probably a sign you don't want to be doing business with that particular ISV. If they do, but the updates break the application, similarly. Besides, you're testing on non-production machines before pushing updates to the production machines, right?

Can I check all packages against a particular OS level? On Solaris, I can say "Check that I have all packages released in Solaris x.y.z patch 5, which was released on June 2, 2005"? Can I do that with Yum?

Conceivably, though, there's no reason why RH, or anyone else for that matter, couldn't put together a series of snapshot repositories. Then you could do that with yum.

That would be a very odd thing to do in FOSS-world, though.

Re:Evidence of problems with packaging systems

[IpalindromeI]

Actually, dpkg -l gives you the package name, tells you if it's installed, what version is installed if it is, and shows the one-line description.

Re:Evidence of problems with packaging systems

[arkanes]

You're just playing with definitions. Someone with Debian Woody will have the current version of GLib defined for Debian Woody, unless they either installed a different one manually, or chose not to update. There is nothing about this that is different than OS X or, indeed, any other OS out there. The package is doing exactly the correct thing, assuming the dependency information is correct and just just set arbitrarily - if the app won't run with GLib 2.1, then it won't install unless you update. If it won't run with 2.5, it won't install unless you downgrade (but you probably don't want to, you probably want a new version of the app). OS X has these *exact* same problems, some of them even worse because of just how much Apple will change system APIs around between releases.

The whole point of the packaging and dependency version is to allow regular, dynamic updating of libraries (your "solution" is, in effect, that any update is a new OS version - this is essentially what Apple does), and to provide you with tools to manage the inevitable dependency problems that will come from that. It has jack all to do with "system wide patchlevels" or anything else you're talking about.

OS X absolutely is isolated from outside developments. You won't get improvements to WebCore until there's a new OS release, unless you manage them yourself. Applications what rely on a new version of WebCore won't run, and to make matters even more fun, OS X has no way for you to easily declare this dependency, so you either handle it at runtime in your app or you write a custom installer to check for you.

Re:Evidence of problems with packaging systems

[flithm]

I have a couple of Debian machines, so I know a thing or two. Enough to know that the reason this botched so badly is probably because they didn't give users an updater, rather just expected everyone to read the release notes, and update their system like normal.

It's not such a bad thing to warn people that they need to perform some task prior to updating. But if 1/3 the users aren't following the intended procedure, also given that they experienced a number of problems prior to release... they should have taken more steps to ensure people's system wouldn't be dead.

If it was say on out of ever 100 users or maybe even one out of ten, I would agree that the users are at fault... but one third!?

Re:Evidence of problems with packaging systems

[AKAImBatman]

You've described the situation pretty much to a T. And yet (amazingly) the OS X solution works, but the packaging solution doesn't. Shouldn't that tell us something?

Re:Evidence of problems with packaging systems

[arkanes]

As a developer, the OS X solution sucks ass. It doesn't work. And the packaging one does. So what it tells *me* is that packaging is better.

As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay (I use both a Mac and Linux - and Windows for that matter which is in a shithole no matter how you look at it). So it's either a wash, or a win for packaging, depending on how much you like to play with your system.

Re:Evidence of problems with packaging systems

[ArsonSmith]

One persons strenght is anothers weekness. I see it much more of a Linux strenth. The ability to upgrade only what is needed. Install only what is needed. It sure makes upgrades a lot less painful. You can also upgrade parts at a time over time with a simple apt-get update/upgrade or up2date.

Upgradeing to sp2 or sp3 or sp4.5b1 or spA5G or sp1138 or what ever various degree of patches upgrades and service packs makes it much more difficult.

Re:Evidence of problems with packaging systems

[arkanes]

The one-third number was taken directly from Bill Allomberts ass. Note that it wasn't even "1/3rd of my machines failed", or "1/3rd of the people I know had trouble", which would still be useless, just that he guessed about a third would have trouble. Don't judge anything based on that.

It would probably be a usefull patch to apt to have it update itself (and it's dependencies) before doing a dist-upgrade or anything. Of course, you have to get people to update just apt to get the updated apt which will update itself....

Re:Evidence of problems with packaging systems

[ArsonSmith]

And in case you're interested run the command with:

$ COLUMNS=150;dpkg -l

and you can actually see the full listing. For some reason you have to run it like that if you try to set COLUMNS otherwise for some reason it gets unset right away. Not sure why.

Re:Evidence of problems with packaging systems

[AKAImBatman]

As a developer, the OS X solution sucks ass. It doesn't work. And the packaging one does. So what it tells *me* is that packaging is better.

Now there's a new one. As a developer, I find the solution about equal. A library is a library. In the case of OS X, I have a bunch of great APIs already available to me. In the case of Linux, I have to download and compile my own. The key difference is in distribution where we start overlapping with users. As a developer, I have to *hope* that a Linux user gets the right packages installed. On a Mac, this issue does not exist.

As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay

Now that's just a lie no matter which way you cut it. On OS X I simply check my system version against the required one. If they match, I download and run the application. No installation required. On Linux, I must first resolve all the dependencies and ensure that all the packages are installed. This works great for the first month or two of the distro's release, but as programs start appearing who's dependencies can't be automatically updated, I begin having to manually fix errors that are preventing a package from being installed. And I have to be careful, because the fix might prevent an existing package from working correctly. All because the core of the system can get upgraded and break the delicate balance of dependencies.

Re:Evidence of problems with packaging systems

[flithm]

Well I have to admit I feel kind of stupid. I don't know what made me trust the journalistic integrity of anything posted on slashdot.

No kidding, where the hell did get get that number?

Anyway you're right, it would be a good thing for apt-get to update itself. I know that the gentoo's portage system does this automatically.

Re:Evidence of problems with packaging systems

[wobblie]

And there is always some post like yours, which clearly demonstrates you haven't even tried to figure out the answer to this simple question.

rpm systems: rpm -q --changelog
deb systems: /usr/share/doc/changelog.Debian

These are almost always more informative that the kind of crap I see on commercial unixes.

There is no such things as "patch levels" or "clusters of patches" in any linux distro I know of.

It is, in fact, a rather dumb idea anyway.

Each package is updated alone, as it should be.

Re:Evidence of problems with packaging systems

[ISayWeOnlyToBePolite]

They removed xfree3.3 from woody after it was released becurse they couldn't handle the security issues, to much differed from the 4.x versions. Unless you specifically check for removed packages, you're just stuck with the old, apt won't warn you. Sometimes there just isn't an upstream, like for example if you upgrade from woody to sarge not having changed the default mta (it's installed as a base package), then you're afaik stuck with exim3 and that's been dead upstream since quite some time.

Re:Evidence of problems with packaging systems

[EnronHaliburton2004]

rpm systems: rpm -q --changelog
deb systems: /usr/share/doc/changelog.Debian


You dipshit, he's not asking for a zillion pages of notes, he's asking for the patch level. Is that really such a hard topic for you to understand?

Re:Evidence of problems with packaging systems

[Ih8sG8s]

I'm sorry, but you're pulling at straws which don't exist.

In this example, apt will recignize the requirement and pull the required packages down and install them, warning you if doing so will break anything else. This question is moot though, becaue thie issue ebing discussed in this particular thread no longer pertains to the subject at hand, which is the update from woody to sarge.

The whole problem with this issue is that people are stupid, and don't read release notes. One could also say that the debian folks should perahps have fixed the installer to abort if apt had not been patched before system upgrade. They should ahve done this I think.

Your points are well taken, however, the days of monolithic OS releases in free software are long gone unless you want to use BSD. Even then though, in that famously controlled OS, ports can render the point moot. Monolithic systems have a specific use and purpose. For those who need this functionality, they are never going to use package management to begin with, they will roll their own, or simluate it through controlled and processed use of package management features, testing and standardized procedures.

Re:Evidence of problems with packaging systems

[arkanes]

A library is *not* a library. First off, if you depend on anything except the system libraries, you're on your own. And if you use the system libraries, you must ensure that you target a specific OS release version, and you have minimal resources at hand to allow you to target previous versions. Yes, you can just package everything in your app bundle. This is a stupid wasteful solution and there's a reason people prefer dynamic libraries. Yes, XCode will allow you to check that you don't use Cocoa/UI features not present in old versions, no it doesn't work for everything. OS X deals with dependency problems by ignoring them and having the developer deal with everything. A packaging system provides tools so the user and the developler work together to solve them.

On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break. My apps will break because nobody ships apps using anything except the Apple-provided webcore. System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.

What you're describing as a "problem" in Linux is easily solved by not upgrading, which is what you want to do anyway. You don't have that problem on OS X because you don't and can't update libraries. If you didn't update stuff on your Linux installs, nothing would break either. And thats granting your "applications who's dependencies can't be automatically updated", which I have yet to find a problem. If I need to install software manually, and I care about it being tracked properly for dependencies, I'll build a package for it and install it via dpkg/rpm, so everything knows about it.

Re:Evidence of problems with packaging systems

[IllForgetMyNickSoonA]

I stand corrected with respect to the dpkg. What I said for rpm -qa still holds (regardless of what the guy who modded me down thinks of it).

Even for dpkg, it is still true, that the answer didn't have anything to do with the original complaint.

Re:Evidence of problems with packaging systems

[bogado]

I am not aware of those holes and you got me curious, could you point to the holes you're refering? Please?

Re:Evidence of problems with packaging systems

[beforewisdom]

The more you ask people to read the less people will read.

Even I.T. people.

Re:Evidence of problems with packaging systems

[Qzukk]

I'd hate to see software you produce if you consider this a "fix".

I'd love to see your software. Care to share your latest developments in psychic bug-fixing? What magic spells do you use to make bugs in your programs fix themselves without downloading an update?

Re:Evidence of problems with packaging systems

[mandolin]

The closest thing I know of to patchlevels in Linux-land is Debian's different revisions of -stable. I believe it's non-trivial to back-rev these, but Debian's so conservative about patching things in -stable that (in theory) it wouldn't be an issue.

Good luck with verifying Debian packages since I don't know how to do that. On RH, you should be able to verify the entire system w/something like "rpm -qa | xargs rpm -V". But, no, RH certainly doesn't have "clusters" of patches (last I checked).

Re:Evidence of problems with packaging systems

[Burz]

For a system that has only now just standardized its APIs with 10.4, it works brilliantly.

That Apple chose to undertake a prolonged period of OS X evolution is another issue.

Only getting core updates when Apple says its OK is the reason why your users can cope with your software co-existing with other apps on their systems.

Re:Evidence of problems with packaging systems

[Qzukk]

3. Make the upgrade with the ability to fix what needs fixed to support the rest of the upgrade.

So what do you do when your bug is in the upgrade tool (in Debian, in case you didn't know, thats what apt IS)? You tell people to update the upgrade tool first. And now we're right back where we're started. Somehow the (broken) upgrade tool needs to know that its broken and needs to replace itself, without any foreknowlege of its brokenness, but telling the user of the problem and how to update the upgrade tool is met with derision.

Re:Evidence of problems with packaging systems

[wobblie]

Well, dipshit, then you're even stupider than I thought, since the version of the package (patch
level) is both in the filename of the package and in the package name.

Re:Evidence of problems with packaging systems

[paenguin]

Gentoo does this.

When a new port of emerge comes out, you have to donwload it and compile it before you can use it to get anything else.

Re:Evidence of problems with packaging systems

[Phexro]

Actually, the Debian releases do exactly this.

Debian 3.1 ships with a set of 'required' packages, which are the same no matter what system you're on.

When Debian 3.1r1 comes around, there will be some changes and fixes, and these will be reflected in the package version numbers. All systems running 3.1r1 will have the same package versions available, and the same set of required packages installed.

Obviously, if you tinker with the stock install, you will have inconsistent results, but you'll have the same problem if you tinker with a Solaris installation, too.

Want to see the version/patchlevel on Debian? cat /etc/debian_version.

Sorry, I don't see the problem here, unless you're talking about differences between different distributions.

Re:Evidence of problems with packaging systems

[AKAImBatman]

A library is *not* a library. First off, if you depend on anything except the system libraries, you're on your own.

I assume you mean "on your own" from the perspective of XCode not supporting you? Because GCC is still GCC on both systems.

And if you use the system libraries, you must ensure that you target a specific OS release version, and you have minimal resources at hand to allow you to target previous versions.

You make it sound like a bad thing. Progress forward is a *good* thing. The argument here is more about the issues inherent in going forward. In Mac OS X, going forward is rarely a problem. In Linux, packaging errors can commonly build up and cause issues.

Yes, you can just package everything in your app bundle. This is a stupid wasteful solution and there's a reason people prefer dynamic libraries.

It's only wasteful if it's truely something that everyone else will be using. The problem is that the majority of the libaries you use outside the core are not going to be used by other programs on your hard drive. At best, you may find one more. That makes the amount of waste minimal, and improves the user experience overall. If a given API ends up used in a large number of programs, then the vendor should add it to the next OS release.

A packaging system provides tools so the user and the developler work together to solve them.

The problem is that dependency issues should never be the user's problem. Dependencies tend to be a shortcut developers take so that they don't have to reinvent the wheel. That's a good thing. But if you're forcing the user to worry about your development habits, then the user is going to get pretty upset.

On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break.

Indeed. The same thing often happens on Linux. If you upgrade GLib, you may just break a large number of existing applications. Yet if you don't upgrade, the new applications you want to install won't work. Having an API basis per version at least forces the developer to make due with what exists, or wait to release his software until the next version.

System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.

That's my entire point. Upgrading system components is BAD for the user. And since the developer is supposed to serve the user, it's BAD overall. The only upgrades that should ever be done to the core (short of an entire platform upgrade) is security fixes and OS patches. None of which should ever affect the APIs available or the behavior of the system.

Re:Evidence of problems with packaging systems

[AKAImBatman]

When it comes to portable code, OS X offers only the basic POSIX functions. If you want to use a non-proprietary library that's not included in the OS X BSD subsystem, guess what? The situation's just like Linux - except that it's a pain in the ass to package your application for OS X, while it's dead easy to package it for Linux or Windows.

Except that your point is irrelevant. Linux systems use open APIs that are considered quite portable. The issue at hand is that the exact mix of available APIs is constantly changing and unpredictable, even on a single distro. If distros took the tack of creating a stable API base each revision (similar to how Windows and OS X work), then could become far more attractive to users.

Re:Evidence of problems with packaging systems

[stefanlasiewski]

You hit the nail on the head. He's looking for checkpoints.

However, even the CD-based distros are quickly moving targets. There are hundreds of packages, and a dozen different version of each package and thousands of possible varients. You can't really say "I run RHEL 4, version 5, patchlevel 3" because 4.5.3 can STILL be one of a hundred different combination of the packages. This applies even to the Core of the OS.

With Debian, you say something like "I run RHEL GNU/Linux Sarge, with Kernel version 2.8.x.y.z, Glibc version 1.2.3, GCC version 1.2.3, Coretools version 1.2.3". The package versions are precise, but the overall version of OS level is vague.

If you're running a production & staging environment, it's difficult to determine if each machine is running the exact, same OS. A signifigant number of bugs come from these differences between systems.

There should be some way to quickly determine the exact version of the base OS on a zillion machines without parsing the entire package list.

We do this in software development all the time, right? They are called Branches. When I say "Branch 2.1.1", everyone in the room knows exactly what I'm talking about because "Branch 2.1.1" is a very well defined product, and we know the exact version of every piece of software that goes in there, at least in theory.

I'd love the same ability for then I'm talking to other people on an IRC channel. Especially for sytems where the hardware is tightly controled, such as a Sun machine.

Re:Evidence of problems with packaging systems

[pLnCrZy]

"Solaris 5.9 build 100041-23" contains Kernel version X.Y.Z, C compiler X.Y.Z, C libraries X.Y.Z.

That's great, until someone does a "pkgadd -d [some important package]", now your argument might not be so valid.

Re:Evidence of problems with packaging systems

[wobblie]

?

Red Hat releases an update of their distribution every so often, they called things like "RHEL 3
update 2 (3,4,5 etc.). Debian does the same thing (3.0r1(r2,3,4)). Are you really this dense?

Re:Evidence of problems with packaging systems

[MuMart]

Zlib: http://news.com.com/2100-1001-857265.html

GDI: http://www.crime-research.org/news/28.09.2004/666/

Re:Evidence of problems with packaging systems

[green1]

well... I'm not sure where I went wrong then... I read the release notes, and I followed them step by step... and something BROKE... big time... after the "upgrade" the machine wouldn't boot, lilo was corrupt, and once I got that fixed I discovered that a few programs were missing that had previously been there (little things like sendmail, apache, shorewall, my pop3 daemon, my imap daemon... etc, etc) once I got those programs back I discovered that some of them choked on the old config files and wouldn't start up... this was a royal pain!

I now have MOST of my server back to "normal" (still have a few cron tasks that are failing for one reason or other that I haven't had time to troubleshoot yet), but I must say I will be a little more carefull with "upgrades" in the future (though how to be more carefull I'm really not sure...)

that said... the idea of being able to do this upgrade from apt is really quite nice... really simplifies things, if it works...

Re:Evidence of problems with packaging systems

[inode_buddha]

You do realize that you can nest RPM commands, no?

Re:Evidence of problems with packaging systems

[Cramer]

Yeah. I was looking for the source of his "30%", too. He also doesn't list any exact problems he had upgrading or anything about his proceedures.

The largest problem here is that the debian installer puts "stable" in the source list instead of an exact release. So, anyone unaware of the new release will not know they have to do anything more than usual -- apt-get update; apt-get upgrade. And dist-upgrade isn't as smart as it needs to be... it'll remove apache without even offering to install apache2.

Re:Evidence of problems with packaging systems

[Cramer]

(it's the "portage" package, btw)

This is not 100% true. You don't have to upgrade portage to continue merging (or building) packages. Having had gentoo fubar portage one too many times, I kept it locked so it's not even a canidate for upgrading. (I don't mess with gentoo's much anymore.)

Re:Evidence of problems with packaging systems

[Cramer]

apt-get -u dist-upgrade and look at the packages it's going to remove, upgrade, and add. I stopped right there with the very first package... apache. I'm not in the mood to convert my apache1 to apache2 right now. (I also have to make sure it doesn't touch bugzilla at all. It's been highly customized.)

Btw:

[cramer:ttyp0]dominion:~/[12:17am]:uname -a
Linux dominion 2.3.42-SMP #11 SMP Sun Feb 6 20:06:02 EST 2000 i686
[cramer:ttyp0]dominion:~/[12:17am]:cat /etc/redhat-release
release 4.1 (Vanderbilt)

I have a slackware 2.1 machine (1.2.8) around here, too.

Re:Evidence of problems with packaging systems

[listen]

The packaging system is still called Conary. The distro made by its creators is called rpath.

I usually make my judgement of software on something more than an ad-hominem ... and to be honest, I think that being a bunch of guys who were a key part of making the most commercially successful distro isn't the damning indictment you want it to be.

Anyway, I don't really care about the particular implementation. Its the idea of transactional upgrades and easily derived distros that is interesting. These are features that could be added to apt, yum, or smartpm.

Re:Evidence of problems with packaging systems

[Qzukk]

OK, lets start over from the beginning.

- New distribution is released.
- New distribution includes new and improved upgrade tool capable of dealing with circular dependencies because the new distribution has circular dependencies on certain libraries.
- New upgrade tool requires new libraries
- Old upgrade tool cannot resolve the circular dependencies required to install those libraries and thus the new upgrade tool and the rest of the distribution.

So since telling the users to upgrade the upgrade tool by hand has been ruled out, I'd like to hear you propose some way of fixing this, in or outside of the box.

Go ahead, pop my blood vessels.

I hate to laugh, but...

[LearnToSpell]

Schadenfreude, I think they call it. Testing for how long, and now this? Ah well. It'll get worked out. Gotta release at some point to find all the ugly bugs. :-P

To whom it may concern.

[ShaniaTwain]

Everything is falling apart. You may experience some discomfort. Just thought we would let you know. have a nice day.

Typical Debian!

[JimDabell]

Obviously this was a rushed job. Typical Debian, always cutting corners, never taking the time to do things properly :P.

Re:Typical Debian!

[Sevn]

Good point. I know I'm getting bored. I installed Gentoo once over two years ago, spend two freaking weeks configuring it, and haven't had a problem since. Perhaps I could recapture the unstable glory days of Linux by installing unstable Debian.

Re:Typical Debian!

[XMyth]

You're telling me! I almost considered switching back to Windows because my Gentoo system is just getting too boring!

Re:Typical Debian!

[Saeed al-Sahaf]

You can laugh all you want. Funny, sure. All the Linux geeks turning their collective nose up at Red Hat. But, do they have problems? YES! Like this? NO!

Red Hat: Not Cutting Edge But Stable!

Re:Typical Debian!

[Janek Kozicki]

oh well, I installed sarge on my laptop in three hours (I was in hurry, because I had to show a presentation during a meeting, so I exacly remember that I did it in three hours). And I had no problems since then.

It would be a sad compromitation if I said that I cannot show a presentation because my newly bought laptop is not ready!

Re:Typical Debian!

[Burz]

No, not like this. Worse.

RH radically changes APIs with abandon and breaks 3rd party software more than any other distro I've seen.

RH/Fedora are great if you want to run a [i]cutting-edge[/i] server that sticks to the supplied software base. As for my "Red Hat Compatible" apps like Rational Rose and VMware, they kept breaking with each new RH/Fedora release while they kept running through Debian upgrades.

I was waiting for Sarge but then came Ubuntu.

[Anonymous Coward]

Any reason why I should switch from Ubuntu to Debian?

Re:I was waiting for Sarge but then came Ubuntu.

[guyfromindia]

Exactly.. Ubuntu came in at the right time ... I dont think I will go back to Debian..

Re:I was waiting for Sarge but then came Ubuntu.

[varmittang]

Ubuntu is more of a desktop, latest updates type distro, while Debian is a strong, server type distro. So which do you need, depends on if you want a desktop or server, make your choice.

Re:I was waiting for Sarge but then came Ubuntu.

[ecliptik]

As of this week I started using Ubuntu and Sarge in conjunction.

Hoary Hedgehog is running on my new laptop with Sarge running on my backend file/web/mythtv server. Together they are extremely powerful and I feel that all my server and desktop needs are satisfied with each doing what they're best at. Is it really so hard to understand "right tool for the job?"

Re:I was waiting for Sarge but then came Ubuntu.

[GreatBunzinni]

Still, Ubuntu isn't the cleanest distro out there. I switched from Mandrake 10.1 and while Mandrake handled everything out of the box without a hitch (even that damned genius mouse that even the genius people didn't knew it was supported under linux), Ubuntu couldn't even automatically sort out multiple soundcards and they even can't sort out that problem in their support forums, which is a shame. All the other relevant distros out there do that easily and automatically.

Maybe in the future Ubuntu is cleaner. Still, stability-wise, it leaves a lot to wish for.

Re:I was waiting for Sarge but then came Ubuntu.

[Azzhole]

Not unless you're a moron ? Best to pick a distro and stick to their own repositories and research dependencies BEFORE you apt-anything_> The Buntu Twins , K and U , have everyting you need and it's been rung through the ringer lately. Libranet is a rock until some idiot has to apply "testing" and crush it. I keep a second drive with the same os to check for fukpzez before using them on the main system. I'm on Xandros this week and caught their upgrade BooBoo before I stuck it on my main box. I'll chill till they get it right and check behind them again. It's called " Beta Blasting final releases YOURSELF" No hurry. If ya want Sarge, truly stable, go over to Progeny and get Developer.. It's a rock, and will roll very slowly to a nice resting spot as STABLESTABLE.//stable.

Re:I was waiting for Sarge but then came Ubuntu.

[dzo]

(warning you might not understand this im working on 2 hours of sleep)

Ubuntu, isnt it debian based? So its not a question of thank god i use ubuntu, that would be a general statement. The Bugs in the debian development do effect ubuntu. But the ubuntu people just make a distro based on debian so the ubuntu gang should not have any probems because its updates are controlled by the ubuntu developers and not the main debian people. work with me i could be right or wrong? ( im just trying to learn. :) )

so my point or question is: Ubuntu and debian are the same but different (.?) So the bugs in the recent release in debian should not break ubuntu but as things get fixed will slow the process of a full switch.

i will be sure to sleep more tomorrow night..

Re:I was waiting for Sarge but then came Ubuntu.

[golgotha007]

Ubuntu is more of a desktop, latest updates type distro, while Debian is a strong, server type distro. So which do you need, depends on if you want a desktop or server, make your choice.

Or you can run Fedora and have the best of both worlds. I use Fedora for both critical high-availability servers as well as on everyone's desktop. Fedora is no less stable than Debian. Period.

Re:I was waiting for Sarge but then came Ubuntu.

[advocate_one]

No, the bugs in Sarge don't affect Ubuntu... Ubuntu Hoary was based upon a snapshot of Sid taken several months before the release date of Hoary and then all the bugs in that core snapshot were thrashed out... It didn't help though that Gnome 2.10 and KDE 3.4 went into the mix in the final couple of weeks before release. I actually found I was running Gnome 2.10 the very day of the official 2.10 release. I'd done an update the night before and not checked...

Re:I was waiting for Sarge but then came Ubuntu.

[sublimespot]

Ubuntu is a desktop distro

Sarge (Debian Stable) is best used as a server distro.

In my opinion you wont be happy running a stable distro on your desktop. Within a few months you will be complaining that your software is out of date.

You should try Debian Unstable... and you didnt have to wait.

well duh

[Tharkban]

Well duh, if you wait that long between release cycles...you're going to have some major problems upgrading, as everything you had was ancient and everything you're upgrading to is mearly old.

I love debian for their philosophy; however, when I tried their distribution and it downgraded the kernel from 2.4 to 2.2 when 2.6 had already come out....I don't think I even started X before deleting it. Maybe I'd have had a different experience if someone had told me "testing" didn't mean what it usually does.

All of that said, it seems these problems could probably have been avoided with more testing, :( .

Re:well duh

[m50d]

Why? Did you have an actual problem with 2.2? Or did you ditch Debian because it was making your e-penis feel small? It's rock solid stable, which is more than I can say for most 2.4 and every 2.6 release I've ever tried? They believe in stability, really do. If you know what you're doing they support going up to 2.4 and probably 2.6, but if you don't know how to and don't even read the help screen, it makes sense for debian to assume you don't know what you're doing.

Re:well duh

[timeOday]

Why? Did you have an actual problem with 2.2? Or did you ditch Debian because it was making your e-penis feel small?

I wonder if you have even tried to use Linux on the desktop. Living in the land that time forgot is all well and good until you need drivers for new hardware, or less buggy drivers for old hardware, or want to boot off a cylinder above 1024, or use advanced network routing and QoS, etc etc.

Debian is "stable" in the sense that packages play well together, and don't change much. But that doesn't mean the software inside the packages works correcly and doesn't crash. Does anybody really believe OpenOffice or Mozilla from a couple years ago is more stable than a recent version? I don't.

Re:well duh

[golgotha007]

I just don't get this. People standing up on a soapbox and proclaiming that Debian is stable compared to the other distros is the same as a Pepsi executive claiming that their drink is fizzy compared to other soft drinks.

I have worked extensively with Debian and other distro types (mainly Fedora and Redhat), and I just don't see this stability difference that people claim.

On the other hand, I do like it when my server distro supports some brand new gigabit ethernet adapter or some advanced routing capability. kernel 2.2? For servers? You're joking, right?

So people don't get confused that I might be trolling, I'm not saying Debian sucks. I'm just saying that it's not any better than the rest.

Re:well duh

[Tharkban]

um...I didn't say I downgraded from debian, in this case I think I had had it with Mandrake and wanted to try a different distribution. I tried debian first, after the 2.2 fiasco, on a laptop no less, I quickly tried something else.

Re:well duh

[m50d]

Yes, in fact I'm using it now. If you actually need QoS or something then fair enough, but so many people seem to want to run the latest and supposedly greatest kernel just because they can.

I don't know about mozilla, but I do know that as far as kernels are concerned 2.4 was always more stable than 2.6, that older versions of VLC were more stable than recent ones. Equally I know that newer versions of some other apps are more stable than older ones. In general, I think stability is pretty much independent of which release it is, but packages that have had a lot of testing and bugfixes without new features added - which the debian stable ones have by now - are the most stable ones.

Re:well duh

[m50d]

I haven't seen any other distro that manages to not crash. Most distros are pretty stable, but they tend to fall over once every few months (IME of course). Not Debian.

I've upgraded 6 boxes without problems.

[khasim]

What, specifically, are the apps that will cause the problems and how does he determine that 30% of the boxes out there will have those apps?

I've upgrade 6 boxes and have not had a single problem on any of them. They run a combination of Apache, perl, python, mySQL, php, bind9, DHCP, etc.

If there is a circular dependency problem on an app, but no one uses that app, then there won't be any problem upgrading.

Re:I've upgraded 6 boxes without problems.

[El_Muerte_TDS]

Same here, not real issue for any of the machines I've upgraded.

However, I had to restart `apt-get dist-upgrade` 2 times because some upgrade process went wrong. But in the end it all worked.
(Much like the `run live update a couple of times to get all updates`, or the `run windows update ...`).

Re:I've upgraded 6 boxes without problems.

[Qzukk]

So far I've seen one user with problems with TTF fonts, so if you're trying to pack every font possible on your computer, you'll end up getting stuck on "Regenerating font cache" (this particular user was stuck on ttf-bitstream-vera, so it may just be this particular font, or their language setting (french I think?)).

If someone does run into a circular dependency, I'd suggest using dselect to run the upgrade, or simply going into apt's package cache and using dpkg -i to install all the packages in the circle at once.

Upgrading a library that apt is using shouldn't be a problem, since the old library is loaded when apt starts, and will stay in memory while apt is running. Of course, if apt stops early, after it replaces the library and before it replaces itself, then you have a problem, but thats why apt isn't the only tool for the job. Use dpkg.

All of this assumes you know what you're doing, which by and large I've found most debian administrators fit the bill. That doesn't make this any less annoying, nor does it excuse apt's lousy circular dependency checking.

Re:I've upgraded 6 boxes without problems.

[kie]

I've upgraded 6 boxes as well:-

• 3 servers in a data centre
• 1 server in an office
• 1 laptop
• and 1 desktop machine

the upgrades were smooth and easy, with the machines running variety of packages.

no breakages!

so that's another data-point or six.

Mixing Lilo and some kernel configs not nice eithe

[Gentoo Fan]

We had a Woody to Sarge upgrade fail on boot because Lilo barfed a kernel panic on root mount. Installing grub fixed it. I forgot how the lilo was set up prior to sarge, but whatever. My suggestion if you have SATA root mounts: Install grub before installing Sarge!

Re:Yes

[ari_j]

Somewhere along the way, with about 200 days of uptime running sarge all along, I lost the symlink to initrd.img that Grub pointed to. The vmlinuz symlink was still there, but no initrd.img. I did a remote reboot, and the machine didn't come back, so I had to get the support people at the colo company to hook up a remote KVM and try to find the real initrd.img with the Grub command line to boot it up.

The lesson that I thought I had learned but evidently did not is to double-check your boot-loader configuration before rebooting if your machine has more than a week of uptime.

But I didn't lose anything at all in sticking to sarge. :)

Re:Yes

[Trollstoi]

I was postponing my move from woody for no reason, but now I am concerned. Will they fix this issue or should I stick with woody?

Update took me two days ... grrr

[TekGoNos]

Nice to know I'm not alone.

Suddenly apt-get dist-upgrade didnt do anything good, I had to do an apt-get -f install multiple times until the dependancy stuff was sorted out. In the process, some packages (notably apache and ftpd) were simple de-installed and I had to re-select them manually.

Good for me that it was a server and apache and ftpd were the only important hand-selected packages. I fear for the desktop systems with several dozends of hand-selected packages.

So, I guess it is a good thing that Debian only releases a major update every two years :|

Re:Update took me two days ... grrr

[MarkSyms]

WTF were you doing using "apt-get dist-upgrade" anyway. If you'd read the release notes then you'd now that the recommended way of doing the upgrade was to use aptitude to prevent just those sorts of problems.

Re:Update took me two days ... grrr

[BeBoxer]

Suddenly apt-get dist-upgrade didnt do anything good, I had to do an apt-get -f install multiple times until the dependancy stuff was sorted out. In the process, some packages (notably apache and ftpd) were simple de-installed and I had to re-select them manually.

I can't say for sure that it would have helped, but the instructions specifically say to use aptitude because it handles dependencies better that apt. So while I feel your pain, I'm not sure it's a valid complaint.

Re:Update took me two days ... grrr

[dubious9]

I'm a Ubuntu user myself, but I really haven't come across aptitude before. I didn't know what it was so I looked it up. According to its debian project listing:

aptitude is a terminal-based apt frontend with a number of useful features, including: a mutt-like syntax for matching packages in a flexible manner, dselect-like persistence of user actions, the ability to retrieve and display the Debian changelog of most packages, and extreme flexibility and customization.

So it's an ncurses(?) bases front-end to apt? Ubuntu's wiki adds:

aptitude - Curses viewer of packages installed or available. Aptitude can be used from the command-line in a similar way to apt-get, but only for some commands - install and remove being the most common. However, because aptitude keeps track of more information than apt-get does, it can be considered better at install and remove operations.

Ok, so it's good for installation and removing. But then what to use apt or synaptic for? Just upgrades? Can anybody clue me into why you would use apt or not use aptitude?

Re:Update took me two days ... grrr

[HiThere]

Well, the last time I used aptitude I looked at the screen. It was UGLY!!! I mean, even for an ncurses screen it was quite ugly. They seem to have chosen the colors to minimize legibility.

It's the kind of application that I'll only use when I REALLY must. I use apt, and I use synaptic, but I'll only use aptitude if I REALLY MUST.

Aptitude is for people who don't care about eyestrain. And, in case I didn't mention it sufficiently, it's UGLY.

Compared to Aptitude, dselect is a work of art and beauty. (Well, actually dselect isn't that bad...but it's the only remaining tool in that category I can think of.)

OTOH, outside of appearances the user interface of aptitude is remarkably similar to dselect.

If aptitude has some good features, they REALLY need to graft another front end onto it. REALLY, seriously.

And, also, once when I was having trouble with an upgrade, I decided to check out aptitude to see just how well it handled dependencies. I ended up hosing my system. So I'm not even convinced that it handles dependencies any better.

Re:Update took me two days ... grrr

[Nevyn]

I fear for the desktop systems with several dozends of hand-selected packages.

Now let's be fair, anyone running a desktop on debian stable is enough of a fan boy that they probably helped produce the release notes.

Re:Update took me two days ... grrr

[cortana]

"And, also, once when I was having trouble with an upgrade, I decided to check out aptitude to see just how well it handled dependencies. I ended up hosing my system. So I'm not even convinced that it handles dependencies any better."

I hope you filed a bug report, to ensure that this serious problem was fixed.

Re:Update took me two days ... grrr

[wsapplegate]

> Well, the last time I used aptitude I looked at the screen. It was UGLY!!!

For those who are wondering what this software really looks like, here's a screenshot. Note the description area at the bottom can be hidden, leaving all the screen real estate for the package tree (incidentally, that tree display is an excellent idea, as it makes browsing through the packages much more comfortable than a flat view).

> Compared to Aptitude, dselect is a work of art and beauty.

Well, how to put this... you see, I do *not* choose my system administration software on aesthetic qualities, but rather on their efficiency and adequation to the task at hand. Aptitude allows me to easily (1) locate packages (with `/' like in Vi), (2) add or remove them (with `+', `-' or `_' to purge), and (3) review what will be done (including what dependencies will be (de)installed). Plus, it has nifty features like marking dependency packages as being automatically installed, so they'll be removed if all the packages that depend on those are removed. No more cruft on my systems !

> If aptitude has some good features, they REALLY need to graft another front end onto it. REALLY, seriously.

Well, I for one find Aptitude intuitive and efficient enough (more than enough, even). But if you really feel there must be another interface, by all means, fork it. After all, Open Source is *also* about your right to disagree with the upstream authors.

> And, also, once when I was having trouble with an upgrade, I decided to check out aptitude to see just how well it handled dependencies. I ended up hosing my system.

Well, that sounds unlikely. You see, if Aptitude detects your choices of packages breaks other packages' dependencies, it will (depending on the configuration) either (1) revert your choices before proceeding or (2) show you the broken packages (in red) and flatly refuse to proceed with the installation. So, you can't hose your system unless you fool Aptitude with some hackery (using equivs, editing /var/lib/dpkg/available, etc.). Note I'm *not* saying that's what you did. I'd be more inclined to suspect the breakage you encountered was caused by faulty packages, hence it would have been just the same with synaptic or the good old apt-get.

In summary, I'm sorry you had a bad experience with Aptitude. In my case, this software has been a very valuable tool, especially on headless servers where synaptic is not an option. And it's clearly way, *WAY* more intuitive than the dreaded dselect, at least for me. I hope you will have less problems with it next time. Meanwhile, you would maybe like to get out the reportbug(1) program and file a bug at the wishlist level about the colors. If you can suggest more legible colors (keeping in mind that terminals have a limited set of colors available), it could probably help.

Re:Update took me two days ... grrr

[eraserewind]

Ah, the instructions said it did they? Linux on the desktop, here we come.

Re:Update took me two days ... grrr

[HiThere]

Since I was already having troubles with the updates, there's no way I could have narrowed the case down enough to make a reasonable error report. This doesn't even PROVE that aptitude was worse in that particular case. All it really proves it that it didn't fix the problem.

But it sure didn't convince me that it was any better.

Re:Update took me two days ... grrr

[HiThere]

But why would I fork aptitude, when as far as I can tell synaptic is superior?

Actually, I usually use apt-get, but I frequently use synaptic when I need to figure out which packages to use. And I occasionally use dselect (rarely). Occasionally I'll use dpkg.

But my experiences with aptitude have not been satisfactory. That it's so hideous is merely the start of my problems with it. You say "But you can search using '/'", and to me that only shows that you haven't used dselect. Aptitude swiped that protocol from dselect (which probably took it from vi which took it from ed...it goes back to system V).

And NO, I wasn't doing anything particularly stupid. The problem was in the way I was mixing the unstable tree with the testing tree. And yes, I knew it was dangerous...but I haven't hosed my system that thoroughly since the time I used --force on an apt-get dist-upgrade (on a system that was a mix of woody and testing...several years ago). But THIS time I didn't use force, or anything that I recognized as equivalent. (The aptitude experience was about a year, possibly a bit more, ago. Some of the details have slipped away. I don't really blame aptitude, as I was trying to recover from installing something injudiciously...but it certainly didn't win itself any laurels. In my estimate, I've no real reason to consider it any worse than apt-get or synaptic, but I've certainly no reason to consider it better. [They didn't fix my system when I tried to use them...but they didn't hose it either. OTOH, an unstable system IS a chancy thing to work on, so it's unfair to blame aptitude excessively.])

Re:up2date works fine... as does my own python scr

[mthaddon]

up2date doesn't provide distro upgrades. It provides updates to a specific distro, but there's no way to upgrade from within up2date from FC3->FC4 or RHEL3->RHEL4. This "breakage" is about upgrading the distribution, not updates within a release cycle.

Re:Why should I upgrade?

[Tharkban]

yeah, that thing will probably outlive us. No need to worry for a while. You picked the right distribution for what you wanted.

Re:Wants them to use modern testing practices?

[wallykeyster]

But I thought that all that free open source manpower solved all these quality and security problems?

Ah shucks! A big ugly troll and me with no mod points...

Re:Mixing Lilo and some kernel configs not nice ei

[SpiffyMarc]

My brain exploded trying to parse this sentence.

And we wonder why we aren't taken seriously by management. ;-)

so long and thanks for all the FUD

[costela]

This is FUD, even by Slashdot standards.

The problems do exist, but the "severe breakage" described does not implicate unbootable machines or unusable software. Cyclical dependencies mostly mean the algorithm used to select packages for upgrade or instalation will not run as expected and probably leave the problematic package on hold.

This is not a new problem and affects Debian mainly because of it's distributed and loosely coupled model of organization, where integration problems can go by unoticed for quite some time.

The original mail intended to push more developers into taking action about these integration errors and make sure the upgrade paths are always clear, which is a very big and important task.

I, for one, hope his message doesn't fall on deaf ears, but also hope it doesn't generate more FUD like this.

Re:so long and thanks for all the FUD

[bogie]

I guess if your a vocal Debian user you have to expect this though don't you? Debian users claim seemless upgrading is a tenant of their distro. Along with stability, being able to upgrade the same distro year after year is one of the two major features of Debian. So when you lose that, it is a big deal. Also severe breakage means different things to different people. When a distro you expect to work perfectly and be worry free suddenly doesn't do what its supposed to I can see why this is a big deal.

"This is not a new problem "
Then why isn't that brought up by Debian users constantly when seemless upgrading is brought up?
I don't think your call of FUD is entirely justified.

Re:so long and thanks for all the FUD

[shadowpuppy]

What FUD? There are some serious issues. I tried upgrading ssh on test copy of our mailserver here. It decided to remove sendmail and apache along with quite a few other packages. Which normally I could have dealt with. However this time it didn't ask to continue like it ussually does, it just went ahead and did it. Fortunately it's a test machine so I can try and try again, but it's still a real problem. Especially since on most servers we'd have just have done the dist-upgrade directly. We don't have the time or the resources to devote to proper testing.

Re:so long and thanks for all the FUD

[costela]

FUD != Lie

I agree there are problems*, but the nature of machine upgrading is interactive, as such, the difference between "unusable service after upgrade" and "problem during upgrade, with services left operational" are enough to justify cautious wording when reporting said problems, not bold accusations of "severe breakage upon each and every upgrade", which is what it sounded to me.

* even though I haven't seen a scenario like the one you described, having upgraded 5 servers from vanilla Woody to Sarge, with SSH, Apache, MySQL, Courier, Bind, Samba and Amavis,

Re:so long and thanks for all the FUD

[myowntrueself]

Even so, any outfit that upgrades production systems from woody to sarge without first testing the procedure on virtual environments *deserves* to lose the business.

Its called 'survival of the least dumb' (something like 'survival of the fittest' but we are talking about geeks so 'fit' doesn't apply).

Seriously, I expect this to happen where I work; we've already had people randomly decide to upgrade production systems to sarge. Its just a matter of time before we are pulling out the backup tapes.

Re:so long and thanks for all the FUD

[green1]

"does not implicate unbootable machines or unusable software"

well... maybe it is unrelated to this article, but my upgrade had exactly that, many packages went missing (apache, sendmail, etc etc) and lilo became unusable preventing the machine from booting... I would call that "severe breakage"... it's mostly fixed now... but what a pain....

What's your setup? Can you test it?

[khasim]

If your setup is simple enough, just clone your drives and test the upgrade process on the clones.

If anything goes wrong, you can just drop the originals back in and everything will be back to the way you started.

You should always test new deployments before putting them into production.

Re:What's your setup? Can you test it?

[Trollstoi]

My Debian machine has no floppy drive and no cdrom. If I break anything it will be a pain in the ass to open it to reinstall the OS, or switch hard drives.

Why didn't it stay in freeze?

[m50d]

I have been among those criticising debian for its long release cycles, but the big advantage of them was that releases weren't released until they were done. If there were that big breakages, why didn't they leave it frozen until they were fixed?

I don't think testing all the way along is the answer, that way nothing would get done. It's great that Debian has a period devoted solely to testing before the distribution gets released, it means things get fixed. It's hard to be motivated about fixing things that are probably never going to be released (because there will be a new version before the actual release)

Version is obsolete

[Profane MuthaFucka]

The very concept of "version" is obsolete I think. There should never be a big-bang system upgrade, and there should never be a fixed version number for a Debian system. Packages should have versions, and those should be upgraded. Distributions should not be numbered.

The ideal way to handle things is to roll out upgraded packages when they are ready. If you upgrade your system once a day or once a week, you should not ever have to deal with more than a handful of updated packages. Over time, everything would eventually be upgraded.

Re:Version is obsolete

[Urban Garlic]

Unsurprisingly, Debian already lets you do this -- if you keep your sources.list pointed at "testing" all the time, you would get more or less this behavior, with the caveat that cruft would probably never be removed. (Python 1.5.2, anyone?)

I am planning to do this with one of my boxes at home, for that best-of-both-worlds feeling.

Re:Version is obsolete

[EvilGrin666]

Your describing Gentoo's package management system, Portage.

Re:Version is obsolete

[jdunn14]

I agree with you to some degree, but what's wrong with marking certain points in time as "distro. X version Y" The marking is orthogonal to what you're suggesting and plays a valuable role for tracking problems. If someone asks me to look at a box and says it has RH9.0 on it I know about what I'm looking at. Makes life a lot easier. For boxes that I admin and am familiar with I know what they are and what to expect, but being able to sum up the software install in a sentence is really useful when I need to look at a different box.

Also, keep in mind that some upgrades are pretty major, and do break a number of things (think of something like the glibc API changing). Having a distro version number that corresponds to when that happened is once again useful to keep administration simpler. Supporting all possible combinations of packages is untenable, however, supporting an updated distro X version Y is a little simpler.

Re:Version is obsolete

[m50d]

You don't get enough testing that way. Say some obscure package off disk 11 gets upgraded. Now, do they really have the manpower to ensure that hasn't broken some other obscure package off disk 10? For every single package, and every version? No, of course they don't. Wheras when they do a release, they only have to test that all of the packages in the release work together (which is easier because it mostly just means install all packages and then test each package, there's a few packages where some are known-incompatible so you have to test for each possible version but that's all). And therafter you know when you install that version that whatever package combination you select, it will work.

Re:Version is obsolete

[wsapplegate]

> if you keep your sources.list pointed at "testing" all the time, you would get more or less this behavior, with the caveat that cruft would probably never be removed.

Like I said in another post above, Aptitude can help you in such a case, as it will automatically remove unused dependencies (assuming you checked the "Remove unused packages automatically" checkbox) when installing new packages. For the packages that are already installed, use the `M' (_capital_ M) key on those you don't explicitly want. If they aren't needed anymore, they'll be immediately marked for deletion (I suggest you further use the `_' key to make sure their config files are purged, too). Hope this helps.

Re:Wants them to use modern testing practices?

[Enoch Lockwood]

Ha-ha, you little troll. You're not as funny as you think.

The security track record of free software has already clobbered that of the closed source products and we're going to leave you even further behind in the future. Why? Because it is inevitable and we have the moral higher ground.

Continue waiting...

[MECC]

This is, after all, Debian

Apt Would be Unbreakable

[Greyfox]

If they statically linked it. Which they should really do for a base level of core utilities anyway. I've been burned by library upgrades and crippled recovery processes several times in the past because the correct libraries were no longer available. For something that might have a library pulled out from under it like apt, it really makes sense to incur the size penalty so that you never have to worry about it dying on you when you replace system libraries.

Re:Apt Would be Unbreakable

[Spazmania]

That's not quite true. For example, the staticly linked apt in a previous upgrade could run in to trouble looking up DNS entries. The problem? /etc/nsswitch.conf got upgraded and the staticly linked DNS library didn't understand some of the new options.

However, offering a staticly linked apt would probably have helped.

Re:up2date works fine... as does my own python scr

[Spazmania]

I haven't had problems with up2date on my production server

Bully for you. Personally, I've had trouble with up2date getting stuck in an infinite loop when it tries to remove the old version of the just-upgraded rpm about every 10th rpm that it upgrades on two of my production servers. I have to kill it and remove the old package with rpm -e.

Don't even get me started about how rpm usually silently replaces your config file with the stock config file during an upgrade.

And this is on minor security upgrades. Red Hat doesn't even attempt to upgrade from one major release to the next while the system is online. You have to take the server down for hours for that.

Re:Mixing Lilo and some kernel configs not nice ei

[BeBoxer]

fail on boot because Lilo barfed a kernel panic on root mount.

Whiskey. Tango. Foxtrot. Lilo properly loading the kernel and the kernel mounting the root fs are quite different operations. I had a box fail to reboot cleanly after upgrading, but that's because I failed to re-run LILO after upgrading. Duh. But what exactly happened in your case?

Re:Wants them to use modern testing practices?

[PepeGSay]

It's not really a troll. How many times have you seen people on here touting manpower and availability of resources as the solution to these problems. I was just pointing out that *process* is extremely necessary to even make the manpower side of the equation effective.

hehe

[griasr]

funny this gets posted 5 minutes after i succesfully upgraded :)

Just upgraded one box

[Efinel]

What I'd say :
Nooooooo !!!!

Not a troll, it is reflective of this community.

[PepeGSay]

How many times have you seen people on here touting manpower and availability of resources as the solution to these problems. I was just pointing out that *process* is very necessary to even make the manpower side of the equation effective.

Had this problem yesterday

[barik]

I had this problem yesterday, a routine update lists the following:

5 upgraded, 0 newly installed, 80 to remove and 9 not upgraded. Need to get 4152kB of archives.

80 packages to remove? If I proceed with this upgrade, it would just nuke evolution, gnome, nautilus, and a bunch of other important packages that I use on a daily basis.

Re:Is anyone surprised?

[Rei]

Amen. And no matter how many repositories you add, you never seem to be able to find the package that you want.

I've had a lot better luck with apt for rpm on Fedora 3 and 4 test, but it still has its problems. Apt requires way too much configuration - hunting down dozens of repositories, tracking down their signatures, finding that the signatures of some repositories change and confuse the entire apt process, etc. Apt gets confused too easily as well - you get one broken dependency (even if it was broken on purpose because it was an innocculous problem), and it refuses to do anything until you fake that the dependancy is met. And then there's the fact that if apt thinks it has a combination of packages that works and then a single one of them has a problem, it doesn't try any other combination or try to download the bad file from a different source; it simply fails.

Making apt "hardier", with more of a central authority of repositories (with trust levels) and easier key-getting mechanisms, more retry ability, and taking on some of the "emerge" abilities (i.e., if apt can't meet a dependancy with a binary, it gets and builds a source package that works with the local system) would be a wonderful thing.

Use aptitude, not apt-get, for upgrading

[Anonymous Coward]

You might want to read the release notes before upgrading:

http://www.debian.org/releases/sarge/releasenotes

...which specifically recommend using aptitude rather than apt-get.

It is still simple.

[khasim]

You take the drives out and you use a different machine to clone them. A machine with a floppy or CDROM.

If I break anything it will be a pain in the ass to open it to reinstall the OS, or switch hard drives.

Huh? How hard is it to switch hard drives? Is there some particular reason you don't have floppy or CD capabilities?

Re:It is still simple.

[Qzukk]

Hell, why screw with your hardware? If you've got the drive space, dump your filesystem. If you've got some weird filesystem, create a big-enough file and loopback-mount it and copy everything onto that. Use parted or LVM to shuffle partitions around and make a second partition from your free space and copy onto that.

It just takes a little creativity and know-how, is all.

Re:It is still simple.

[Trollstoi]

It's under the dinner table, that's why is so hard to switch disks...

Re:Mixing Lilo and some kernel configs not nice ei

[Qzukk]

SATA changed from IDE subsystem in 2.2 and early 2.4 to libata (and therefore part of the SCSI system) in 2.4 and 2.6

Re:Mixing Lilo and some kernel configs not nice ei

[Qzukk]

He's using SATA and the newer linux kernels moved SATA from IDE to the SCSI subsystem.

So all his fstab entries using /dev/hd* and his lilo root=/dev/hd* lines became wrong.

Sucks to break everyone's Woody...

[benjicom]

oops =)

Re:Cyclic Dependencies ?

[BinaryLobster]

Think of this as trying to upgrade from Windows NT to Windows 2000. Sometimes things break in a version upgrade.

If your going to put it on a spare box, you won't be upgrading anything, so this issue shouldn't effect you.

------

Now where is my flame proof armor....

Re:Why should I upgrade?

[Spazmania]

From the release notes:

While nothing prevents you from continuing to use an obsolete package where desired, the Debian project will usually discontinue security support for it a year after sarge's release[3], and will not normally provide other support in the meantime. Replacing them with available alternatives, if any, is recommended.

I don't know if this means that all security updates for woody will be discontinued in a year, but that's the implication.

Re:Cyclic Dependencies ?

[Limburgher]

No. This sort of thing is extremely rare. Having used up2date, apt and yum on fedora, and apt on debian for a long time. I've even done quite a bit on Slackware. Been doing this for maybe 6 years.

I've never run into a single cyclical dependancy, which is when package A needs package B, which needs package C, which needs package A.

Flawed argument.

[guacamole]

You know exactly what the OS contains--- "Solaris 5.9 build 100041-23" contains Kernel version X.Y.Z, C compiler X.Y.Z, C libraries X.Y.Z.

No, you don't know that. 100041-23 is only the kernel patch version. What about other patches? Did you install it through the recommeneded patch cluster? Or the security patch cluster? Or was it the Solaris update cluster? Or maybe you installed this kernel patch as a part of the "Java" patch cluster? There is no such way as patch level on Solaris for overall system.

Re:Flawed argument.

[greed]

There is no such way as patch level on Solaris for overall system.

Similarly for AIX; the system is updated by applying updates to each "fileset" (smallest selectable grain of install).

They (IBM) do provide an "oslevel" command which will vet the current installation against known maintenance releases. But most admins on production boxes patch only what they need, and that's really easy to do on AIX.

The fileset dependency information on AIX will prevent you removing something that is needed by another fileset. It is possible to craft a dependency that will request specific vesions and not accept newer versions.

In general, that's not needed. If you install a newer fileset, everything still works with it.

The main exception is C++. Unless you are very careful with your class definitions, it is very easy to break binary compatibility. You have to be extremely cautious about anything that affects the virtual function table layout, as well as the usual rules for POD type (plain-old-data, C-style structs) compatibility.

AIX provides a way to have multiple shared objects in a single .a file, only one of which is available for linking. Solaris (and Linux) use the libfoo.so.V convention, where you set the soname in libfoo.so.V and use a symlink to the latest for the linker.

But you have to have done that right when you first set up your library. I've seen uselessly versioned .so files on Linux and Solaris--they don't have the soname set, so applications link to the "plain" .so version, so having the old and new one on the system doesn't work--you always get whichever one the .so symlink points to.

A lot of this is solved problems. But very few people know the solutions, and others often aren't interested in listening to people who do know how to construct dependencies, or build shared objects robustly, and so on.

Always existed!

[Skiron]

These problems were always there in the last Debian release - it's just such a long time ago all Debian users forgot about them (the debian see! scrolls recorded it)... ... good job I use Slack ;-)

Re:Always existed!

[Cro Magnon]

Most Debian users weren't even alive during the last release!

How about just using a live-cd to do the updates?

[leereyno]

This makes me wonder why the upgrade process is being run under the target installation in the first place. How about upgrading the system off-line through a live-cd of some sort?

This live-CD would be able to access the installation's filesystems and examine the configuration, particularly the database that APT keeps of the installed packages. The relevant updated packages could then be installed without worrying about clobbering libraries and/or other files that the update process is dependent upon.

At the very least this should be an option to fall back upon. The update process should examine what needs to be updated and then advise the user on whether or not it was safe to run the update from the installed system or whether the live-CD method should be used instead. If you're upgrading from one major release to the next, then you're almost certainly going to have to reboot anyway regardless of what upgrade method you use.

Lee

Re:I have never understood...

[IntricateEnigma]

I'll admit to being only partially familar with Linux and how it works, but I've seen how the principle holds true for Windows systems. I've never upgraded a machine to another version of Windows OS. I always install the new OS on a fresh partition with the old OS and files safely backed up somewhere.

I know linux doesn't nearly have the same problems as windows though (which seems to need a fresh reinstall of the same OS once a year) but it appears some of the same principles hold true across the board.

Is there really some type of utopian OS where upgrades install perfectly as you want them too with minimal user intervention? (or one that theoretically could be?)

static

[zogger]

static compiled-wave of the future. Disk space=cheap.

Re:static

[bill_mcgonigle]

static compiled-wave of the future. Disk space=cheap.

There's something to that, but imagine having to download every program that links to OpenSSL every time they patch a vulnerability.

You didn't get DSL out on your farm, did you?

Re:static

[lisaparratt]

A good thing too, since you'll be using a hell of a lot of it for swapping the 50 copies of all the standard libraries you've got resident simultaneously, now that the system can't reference count dyanmic libraries for paging.

Re:static

[zogger]

is OSX really that slow? How do they do it?

Re:static

[lisaparratt]

No, it's not that slow, but then it rarely ever statically links.

Apps on OS X are in fact a directory full of executables, libraries and resource data. When looking for a dynamic library, the first place it will look is inside the application directory. Hence, applications can overcome version hell if need be simply by embedding the right version of the library. This is not, however, the same as static linking, and it's also not mandatory - OS X still uses dynamic libraries.

A simpler solution

[Laxitive]

I understand the problem you're discussing, and what you suggest is one avenue to solve that problem. But I think that there is another, potentially simpler solution that should solve all the major problems with package systems: get rid of the idea of package conflicts.

Circular dependencies are not a problem - if you view the set of packages and their dependencies as a directed finite graph - it's easy to come up with an algorithm for reliably figuring out the closure of dependency relations for any given package or set of packages.

Introducing the idea of conflicts throws the whole system out of whack. I don't have a proof for it, but it seems very intuitive that trying to figure out a valid configuration of packages conforming to an arbitrary requirements is an NP-complete problem (I think it's reducible to 3SAT).

Getting rid of the idea of package conflicts necessitates a change in the way packages are organized on the filesystem. For one, conflicting file locations must be gotten rid of. I.e. each package affects only it's own discrete set of subtrees in the filesystem.

Secondly, for multiple packages which provide the same service, there must be a way of choosing, for any given user, which set of packages of the potentially multiple providers for a set of services to use. It should be possible to come up with a user 'profile' that describes what implementations that user desires for the services. This needs an extra level of indirection.

Anyway, I think the idea of getting rid of package conflicts is worthwhile, and would remove a whole set of difficult-to-resolve issues from the realm of consideration.

-Laxitive

Re:A simpler solution

[AKAImBatman]

Circular dependencies are not a problem - if you view the set of packages and their dependencies as a directed finite graph - it's easy to come up with an algorithm for reliably figuring out the closure of dependency relations for any given package or set of packages.

Exactly! You're thinking right along the same lines I am. The key is to view the system as a whole, because that is how it will operate. Once the system *is* whole, then many of the circular dependency issues go away. It's only through the concept of componetizing dependent components that we arrive at the issues common to packaging systems. What we really need to work out is how it might be possible to create a distribution system that doesn't exhibit these issues.

My thought is that a system core that can be treated as a whole is half the solution. The other half is discrete applications that don't attempt to upgrade the core, and keep all non-core APIs to themselves. If a particular library starts popping up across several applicaitons, it can then be added to a future version of the OS core. :-)

Re:A simpler solution

[IpalindromeI]

For one, conflicting file locations must be gotten rid of. I.e. each package affects only it's own discrete set of subtrees in the filesystem.

This isn't a new idea, and you can do it right now. Just install your packages from source and while building them, make sure that either:

1. You link everything statically, or
2. All libraries required for an app get installed within that app's directory.

This way no app will interfere with any other, and you can upgrade any of them without having to worry about library dependency conflicts. The disadvantages are increased disk usage (probably not a big deal nowadays), increased memory usage because libraries won't be shared in memory (may or may not be a big deal, depending on your system usage), and more work on your part. But if these things don't bother you, have at it!

Re:A simpler solution

[kbielefe]

I may have misunderstood, but it seems like you are describing what Gentoo calls slots and services.

When two versions of a software package can coexist and are necessary to satisfy dependencies, they are placed in different slots. Services let the user choose between different system loggers, cron daemons, kernel versions, X servers, etc. Defaults are chosen, but are only installed if another package providing the service isn't already installed.

Don't ask me about their implementation, but I know the result is that Gentoo is highly upgradeable. If I remember correctly, when I first installed Gentoo I had gcc 2.95.x, gnome 1.8.x, xfree86, and a 2.4 kernel. I now have gcc 3.3.x, gnome 2.10, x.org, and a recent 2.6 kernel. I've never had to do a clean reinstall. I have just upgraded the individual packages as they became available.

I always find it interesting when people wish for features that are already available in one distro or another. If your distribution isn't meeting all your needs, shop around. You just might get what you are wishing for.

Re:A simpler solution

[Phexro]

It also means that if there's a patch for a critical security issue in a library, you'll have to reinstall (and perhaps recompile) everything which depends on it.

I have 992 packages installed on my Debian system. Let's say that half of those are written in C. That's 496 packages I'd have to reinstall for one change in libc. It's also nearly a gig of disk space wasted, just on libc.

This is not even remotely practical for people who manage multiple machines, and it's really not practical for an average user, either.

No, I'm not seeing that.

[khasim]

It's under the dinner table, that's why is so hard to switch disks...

And what is it about the dinner table that makes it so difficult to move the box and swap the disks?

Is there a particular reason why you're running it without floppies or CD?

I haven't been to your place. Telling me that it is "under the dinner table" is not giving me any information.

Re:No, I'm not seeing that.

[Trollstoi]

Being under the dinner table makes you have to bend to get it, and that's a pain. It runs with no floppy or cdrom because I only have damaged spare drives and I don't wanna leave the basement to buy new ones. Maybe I'll send my mother to buy for me ;)

Had to baby sit...

[Komarosu]

Fine i had to babysit my upgrade, it wasnt a simple apt-get dist-upgrade...

At first when i did a apt-get upgrade it wanted to a REMOVE all the core packages i use that machine for (ssh, apache, mysql, courier...) i had to upgrade one at a time, making sure nothing would barf. Only at the end did i upgrade APT and then do a dist-upgrade to get everything up to speed

This was a long time in the waiting, of course it wasnt going to be really easy.

Re:Had to baby sit...

[sublimespot]

The release notes clearly said not to use apt-get to do the dist-upgrade. You should have used aptitude

Re:Mixing Lilo and some kernel configs not nice ei

[BeBoxer]

That makes sense. That's not really a LILO bug, as it sounds as though updating the kernel parameters in lilo.conf would have fixed it. That's kind of a nasty change, unless the upgrade script could detect at runtime which drives were on SATA and update lilo.conf/fstab/etc. appropriately.

Re:Cyclic Dependencies ?

[jdunn14]

Lets take the words apart:
cyclic - as in circular, comes back to the original point. example: phases of the moon

dependency - something depended on. program A depends on library B, B is a dependency of A. Of course, B may depend on C.

Putting it all together: circle of dependencies
A depends on B depends on C depends on A
Makes it really hard to decide what to do first. Chicken and the egg problem.

If you have a problem figuring out what this all means, at least head for a linux that is built more for an enduser (I've heard good things about ubuntu, mandrake is usually alright, but I don't have direct experience with either).

Now What Did I Post When They Released This?

[Master of Transhuman]

I said the first 1,500 bug reports would be up by the next morning, and then said "This is what they get for releasing early."

I thought it was supposed to be funny. I guess I'm just not cut out for /. humor.

This is true.

[cdn-programmer]

I attempted an upgrade from woody to sarge about a month ago and it broke my system. I have 1000's of zombies running around. This shows up as a defunct process. Its not the end of the world mind you but you can't kill a zombie since it is already dead.

I have reported this and warned that there will be a lot of folks with broken systems. I was very surprised to hear that sarge went stable before this problem was sorted out.

A sarge install from scratch however is fine. Its just the upgrade that is broken and in more than one place.

Re:This is true.

[jrumney]

I had this same experience a couple of years ago when I needed something that was only available in testing, and tried to set things up so most of my system was tracking stable, with just the things I needed and their dependancies from testing. I ended up needing to install the latest apt from source compiled against the c runtime libraries on my system, then after a couple more problems like this, decided it would be much easier in the long run to track testing system-wide and forget about stable.

I think the biggest problem is that stable has got so far behind that everything including such fundamentals as libc need to be upgraded several major versions in one hit, and any attempts that the developers made to be backwards compatible with the previous version are not enough.

Re:This is true.

[The Vorlon]

- Where did you report this?
- How is an upgrade responsible for zombie processes on your system? These are almost always a kernel problem.

Re:This is true.

[wsapplegate]

> Its not the end of the world mind you but you can't kill a zombie since it is already dead.

Sure you can, just aim for the head. Haven't you seen the movies ? :-)

More seriously, I recently stumbled on this kernel module. I don't know what it's worth (still haven't tested it), and it looks old and unmaintained, but maybe that could help in your situation.

Re:This is true.

[cdn-programmer]

What happens is likely that a parent process is not wait()ing its child after the child dies. These leaves and entry in the process table which contains little more than the return code of the child.

Since the kernel has no idea IF or when a parent will request that return code it is sort of obligated to keep the information araound.

If you kill the offending parent then init() will clean up the mess.

I believe this is due to library version issues.

OTHO, the porcesses that seem affected include privoxy, artsd, fire-fox-bin, and a few others.

I have been scratching my head over this - even where to report it. Is this a bug in the application or a bug in a library or somewhere else.

Re:Cyclic Dependencies ?

[jdunn14]

I usually dont reply to ACs, but come on. Of course user has different meanings. People running protein folding simulations on super computers are users. So is grandma who needs a machine that automatically opens her email. As for the claim that open-source patches are better, they are, for those high end users who care to patch things themselves. For the rest of us, a distro will get the patched version of their binaries out to end users fast enough.

As for the playpen comment. Screw you, lots of people use linux for serious work, both desktop and commonly in the server room. Those supercomputers? not running windows. many running linux. Its getting to the point that you don't have to be an expert to run the system, yes its taken a while, but when it's made by the experts generally for the experts usability is not necessarily the top priority.

Yes I play on my linux box, try the newest stuff, etc. I also write web pages (rarely), do all my correspondence, write software for my job, and play media and games on linux. Basically I do the same things I would do on windows, and I find it less annoying to work with. This is mostly due to the fact that knowing enough about the internals means that I can swear at MS for not providing the expert level interface to go with their wizards. Sometimes a command line is more efficient (Ms may be getting the message if they really are revamping their CLI).

RH - FC

[ebvwfbw]

Someone should say it - RH-FC is still out there (FC-4 to be released Monday). I haven't had any growing pains with it at all, they are up to date and yet not too up to date as to make it unstable. Get to know yum and there is apt-get for FC. You might want to consider switching unless you are really in love with Debian for some reason. There is also Suse but it isn't done yet, they are still suffering transition pains from when they were bought out.

You do have everything backed up don't you?

Re:RH - FC

[metamatic]

With Fedora, he wouldn't have to worry about upgrades removing packages... but he'd have to reinstall every few months when a new Fedora release came out.

Re:RH - FC

[ebvwfbw]

but he'd have to reinstall every few months when a new Fedora release came out.

Why? I haven't reinstalled once since I installed RH 9 and kept upgrading, all the way to FC-3 on a few machines. One machine I think goes clear back to RH 7.3 (300 MHz machine, about 7 years old now but don't try that at home kids! I'm a professional.) and has been upgraded all the way to FC-3. FC also releases about every 6 months (seems like longer). You just have to look and see what is new. I.e. Read the release notes (Yes, someone really does read them. Ok, most of it... Ok, some of it... ).

Re:RH - FC

[metamatic]

I had a Fedora Core 1 system. When Fedora Core 2 came out, the upgrade path was to burn a CD, reboot from the CD, and do a reinstall.

Maybe there was some hackery to let you upgrade using yum or something, but it wasn't supported according to the documentation I saw.

Re:RH - FC

[ebvwfbw]

I didn't have any trouble. I booted from CD, went through the international and keyboard stuff then it found my disk and saw I had a previous installation then offered to let me upgrade or install. I hit upgrade and away it went. About 15 minutes later I was on my way again.

Maybe you had some special hardware? Set up a funky filesystem or something (like Reiserfs)? FC's will load other filesystems if you have a disk for it or reiserfs. Not sure if FC-4 will support it anymore, the latest reiserfs is very new and incompatible with the previous versions. I'm dumping it everywhere.

Sorry to hear you had trouble. If you remember what you did, you may want to open up a trouble ticket on it. Others may have the same problem and are to afraid to say anything. Don't be afraid. The worst that can happen is you get flamed. You may help thousands, perhaps millions of other people.

Complex systems are hard to manage. Period.

[kollivier]

There is too much freedom for even the distributions to make cores effectively. Debian doesn't develop the software, they package it. They have no direct control over compatibility issues between versions in their software. This makes their job a whole lot harder than in commercial OS's where one entity controls both the core software and the packaging.

You mean like Darwin/OS X? A fair amount of that OS comes from FreeBSD. Apple doesn't "control" FreeBSD.

What they do control is their development and testing process. They keep the number of packages *they* maintain down to core system components, and they don't support 1000 variations of their system setup. One setup to build, one setup to test. What I'm amazed most OSS developers have realized yet is that, well, this means they have *expontentially less* software combinations to test and support. You use what they give you, rather than risk hand-building some untested combiation of packages. Consequently, things are much less likely to break and when they do Apple will have a fix to you quick.

Microsoft and Apple don't package third party software for others, why should Linux vendors?

They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.

Well, their first stable release in several years is very broken, and regardless of how hard they've worked, it makes it clear that their development process sometimes lets very critical bugs get into release software. The core issue is that all packages on a system can be dependent on other system packages, which may have version conflicts, etc. There's no possible way to even test all the possible software combinations.

A complex system leads to complex problems. You either reduce complexity, or recruit more and more and more people to try and deal with it. So long as you have an endless stream of volunteers constantly testing and fixing, I guess this could work, but once the distro loses that, it's dead in the water because it can't remain stable. I also feel it's a shame because you have all these resources going into routine maintenance rather than improving the OS.

What I want is not even LSB, but *one* distro with a simple to maintain system. I eventually shrugged my shoulders and moved to Mac. What is odd to me is that despite the fact there's no LSB, all the distros out there are writing separate package management systems that work differently, but are basically all the same in that they are all complex due to dependency issues, and ALL basically are about maximizing disk space and efficiency, as if those things were far more important than my time. And that's how the business and home market thinks - they don't want software that gets in their way and wastes their time.

The sad part to me is that distros like Debian tout their software installation system as a "killer feature", as if the ability to easily install software is a rare thing in Linux and not a commoodity. Most everyone I know equates Debian with apt-get. Well, other OSes have had this "killer feature" for a decade, so long that none of them actually touts it as a feature, and OS X also doesn't have "DLL hell" issues. (Dependencies are provided by the system or by the app, no "variable" system configurations.) No package manager necessary.

Re:Complex systems are hard to manage. Period.

[kollivier]

Windows has about 50 competing ones, and no central repository to get libraries etc. so you end up having to search all over the net for the runtimes.

I never search for runtimes, but then again maybe that's because most vendors whose software I use include any non-system runtimes they need. If you're searching for runtimes, that means you're either a software developer or the software packager is telling you to put the app together "piece by piece". In either case, package management isn't a solution - it's simply moving the problem to another area. (Complex dependency issues which could royally muck up your system.) The solution is to include the runtime with any application that uses it.

OSX only has on 'sort of' installer, but doesn't support uninstall which makes it kinda useless. It has exactly the same library issues as any other OS. It is after all just Unix with a GUI. (try running an app compiled under gcc4 on osx 10.3 for example... they renamed libstdc++ and it's not available as a package, so you have to find a copy, download it, su then put it into the system manually... not so user friendly.).

If you're using a terminal to install software, you're doing things far more advanced than the average computer user does. Most people don't know what su is. They don't have to thanks to bundling.

And here's the complexity issue I was talking about. See, you ask me to try running a gcc4 compiled app on OS X Panther. Why? I'll just build on Panther or use gcc3 and the Panther SDK on Tiger. This is a logical, simple solution. No mucking with libstdc++, no writing some "package" which mucks with that on a *user's* system (and if it screws something up, bye-bye system)... Frankly, it baffles me why people would want to try stuff like this.

As for no uninstaller, yes, that is an issue, but again, it's no big deal unless you're tight on disk space. Most people aren't, and in the future, that'll be even moreso the case. And, if you do want to uninstall programs, OSXGNU has an application that lets you do so, because all packages leave receipts. Again, a minor issue and there are solutions.

In any case, this debate is mostly academic. Ask a majority of Mac users if they're pulling their hair out over software management and dependency issues. They aren't. And unlike Debian users, 30% of Tiger machines (which would be hundreds of thousands) aren't having serious problems. So if this solution works for them, and is vastly less complex to maintain and update, really, why isn't it even worth considering for Linux users too?

Re:Complex systems are hard to manage. Period.

[Burz]

It's very sad, IMO. While OSS projects are trying to make their UI look like the old Mac OS (and crippling it in the process), they're not addressing the Linux user's inability to administrate their own systems simply and effectively.

No one in FOSS seems to 'get' that every home and small office user is basically their own system administartor. Yet they are not offered a structured environment where admin tasks like installing 3rd party apps are trivial.

As a new Mac user, I used to hold out hope that Debian would change Linux desktops for the better. But the only way Debian can help is if it puts its foot down damanding LSB compliance, and creates a new package structure that physically honors this core functionality.

Until something like that happens, things will remain chaotic. The kernel is not a sufficient core for the desktop.

Re:Complex systems are hard to manage. Period.

[AKAImBatman]

(a) Darwin is not FreeBSD, nor is it directly derived from FreeBSD.

Having spent some time researching the topic, I have found this to be just as untrue of a statement as "Darwin is basically FreeBSD!"

As with many things, the truth lies somewhere in the middle. You see, Darwin is based on the Mach kernel, a design intended to improve the state of Operating System research, but not an OS unto itself. Mach was actually built on top of BSD 4.3, as the researchers considered the basic kernel duties to be irrelevant to their research.

When NeXT was ported to the Apple Macintosh, the decision was made to update to a codebase newer than BSD 4.3. The choice that was made at the time was FreeBSD. As a result, Darwin is currently a half-FreeBSD, half-Mach hybrid that contains many of the FreeBSD kernel constructs, but is supercharged with the Mach message-passing semantics.

The command line utilities are used from FreeBSD both because they are very Unix-ish implementations, and because using them is convenient.

OS X is not free or open source, and only Apple gets to choose what goes in it.

Scott McNealy did a very good writeup a few years ago in which he encouraged companies to release non-core software into open source. His justification was that software that wasn't giving you a competitive advantage was just a cost that could be reduced by letting volunteers help. However, software that gave you a competitive advantage in the market should be kept closed for as long as that advantage is maintained.

That is what Apple has done. Darwin, Safari, and other non-critical components are open. Quartz, Cocoa, IOKit, and other competitive advantages are kept closed. Seems to me that Apple is playing the game quite well. :-)

Re:Complex systems are hard to manage. Period.

[Feztaa]

Microsoft and Apple don't package third party software for others, why should Linux vendors?

Because on linux, there's no such thing as software that isn't third-party.

If you look at a distro like Fedora, how much of that do you think is produced by RedHat, and how much of it is "third party"? I'll give you an idea, if RedHat were to stop distributing third-party software with Fedora, then Fedora would no longer have things like: a kernel, a filesystem, a shell, a windowing environment, or even a package manager (yes! 'yum' is not produced by RedHat, it's third party as well).

So where do you draw the line between "third party software that everybody is going to need on the system" and "third party stuff that we can let users install on their own"? Debian takes the stance to simply package everything, and the debian apt repositories have thousands upon thousands of packages in them.

Re:Complex systems are hard to manage. Period.

[kollivier]

Because on linux, there's no such thing as software that isn't third-party.

Depends on your definition of "third party". After all, FreeBSD is open source and wasn't made by Apple, and lots of OSS is available for Mac, so based on your definition of what is and isn't third party, Apple/Mac couldn't make a difference either. But they do. A good definition I go with is "any software for the platform that is not maintained by the platform vendor". With that definition, at least wrt open source, it's the vendor's choice what software is and is not third-party.

So where do you draw the line between "third party software that everybody is going to need on the system" and "third party stuff that we can let users install on their own"? Debian takes the stance to simply package everything, and the debian apt repositories have thousands upon thousands of packages in them.

Simple, draw a line. :-) A vendor says "our OS is comprised of the following software components. Nothing more, nothing less". I mean, no vendor supports every package, so they do all draw the line somewhere (they have to). I perfectly understand that your above reasoning is one of the main reasons why Linux distributions *don't* make a clear distinction, but that doesn't mean they *can't* make the distinction. (And they'll save a lot of resources they could use elsewhere if they did.)

Probably Redundant to say this

[KingBahamut]

But.....UBUNTU!!!!!!!!!!!

Upgrades are going fine

[lal]

I'm upgrading all of my boxes from woody to sarge. So far so good. You need to follow the instructions here
Some perspective: It is a giant leap from woody to sarge. Each server I'm upgrading has a purpose, and the application software to support that purpose has taken a big version jump. Of course, you're going to have issues doing that.

Re:I have never understood...

[Tony Hoyle]

Debian mostly does that, but you probably have to update a bit more often than the stable releases.

I only ever install debian when first setting up a machine. All the rest of the time it gets periodically updated via apt.. don't even need to reboot.

You can make windows last a year? Wow... I'm averaging 3 months and that's even not using outlook or IE and having all the AV/Anti-scumware stuff available running every night.

Exploding up2date and yum...

[jd]

I routinely get up2date and yum into situations they are incapable of resolving. I gave up on gentoo, after I managed to fry their upgrade process, too.

These update systems have very basic dependency checking, as far as I can tell, and complex dependency chains routinely fail. The "correct" algorithm is as follows:

1. For each installed object, determine the list of all available versions (either already installed or online)
   
   1. If a file is indicated, rather than an object, and no object is known for that file, use rpmfind to map the file to an object, add the translation to a translation map, and use the object reference rather than the file reference
      
   2. Try the repository last used for this object
      
   3. Try the repositories listed in the configuration
      
   4. Try the URL(s) listed in the RPM header
      
   5. Try the source RPMs
      
   6. If apt-get is installed, try the apt archives
      
   
   
2. Build a set of installed objects, minus version information, for which a newer version exists, and place the names in a set of unmapped objects
   
3. Select an unmapped object, and:
   
   1. Build a set of objects that are depended upon
      
   2. Build a set of objects that depend on it
      
   
   
4. Move the object now mapped to the mapped set
   
5. Move the two generated sets to the unmapped set
   
6. Set subtract all mapped objects from the unmapped set
   
7. If unmapped set is not empty, go to 3
   
8. If the mapped set contains objects for which no information is known, go to step 1, using the unknown objects for the search list
   
9. For each object in the mapped set, determine the upper and lower version bounds of all direct dependencies
   
10. For each object in the mapped set, find the intersection of the set of limit values, as this will give us the broadest range that will work with what we require
    
11. If the latest version that will not break dependencies is the installed version, skip that object and remove it from the mapped set, otherwise fetch from any repository known to have a copy (based on our indexing from step 1)
    
12. Install all mapped objects, en masse, to avoid problems with circular requirements
    

Because the above system uses set logic, circular dependency lists will work. An object cannot appear in both groups, and cannot appear more than once in either.

Because the above system uses a mix of known good archives, known good repositories and "official distribution points", there is a much greater chance that the required versions will be found.

Because the above system can pull source files, a-la Gentoo, it would work in cases where a repository has been partially updated.

The biggest problem I have ever had with installers is that I have a highly generalized machine, which means a LOT of RPMs, with a very complex network of dependencies. The list is usually resolvable, but frequently requires a lot of manual investigative work, as up2date and yum aren't always able to infer the necessary files and/or cannot find them and/or cannot handle the fact that archives are rarely maintained completely in sync.

Re:I have never understood...

[x.Draino.x]

Yes, it's called Mac OS X.. a close second being Gentoo. /me says goodbye to his karma.

Dude, big upgrades may cause problems!?

[dnamaners]

Oh brother, big upgrades may cause problems, this is not really news. We all backup our servers (or important boxes) before we do ANY upgrade, especially if its this big (woody -> sarge). then we are mostly "safe" when (or if) something breaks. At the very least get a list of your installed packages and backup the "critical things". that ways if X eats Y you know how it was before.

As a complete pessimist I truly expected bad things from this upgrade. I was pleasantly surprised that when I upgraded 7 boxes and 2 servers the worst that happened was one old testing box (a PPC that had not been updated in years probably) wanted to uninstall KDE. At this point I may add, of course when we do say an "apt-get dist-upgrade" we LOOK at what wants to be uninstalled don't we. If somthing we like / need is gona be uninstalled we usually think abit and fix that dependency first (at least I always do).

At any rate, many of these boxes (not all mine) were a mash of headless pseudo servers and desktops running various states of woody, the old sarge and many bits of sid and sarge all muddled together. And they all came through with no real hitches, just a the usual twiddle of the sources lists and may be a quick tweak of the installed kernels in the grub menu (so the right one is default and all entries are sane).

Got it all done in an afternoon, and got on with the rest of the day. All and all, a much better upgrade path than I remember with potato -> woody back when I was younger and much stupider. We now have a much more homogeneous set of light use boxes / desktops and the file servers are set to get their security upgrades and be basically unnoticed for another 3 years if need be.

The pessimist is happy... Thank you to the Debian team, I have been a little less pessimistic for the last 5 years thanks to all your hard work.

*nothing is truly broken and nothing is truly idiot proof by nature, it is all how you deal with it. That is what really defines who is really at fault with the shit rain starts to fall.

Future of Debian usage...

[reed]

Wait, you mean people actually are still using Woody and are trying to upgrade all at once to Sarge?

Nobody uses Woody. Run 'testing' or 'unstable' and upgrade continuously-- that's the best way to use Debian, and with perhaps slightly expanded automated testing of the 'testing' branch, and more frequent moving of packages into 'stable', that could simply be the way it always works in the future; forget these antiquated "distribution releases".

Gee...thanks...

[SamMichaels]

The upgrade wanted to remove half of my installed apps and it kept back the other half. Even after sorting it out (hours and hours), it did something screwy with the ifupdown utility so it never came back from a reboot.

This was the final nail in the coffin for debian. No updates since 2002 and now this.

Re:Cyclic Dependencies ?

[fishbowl]

>I have no idea what a "cyclic dependency" is nor do
> I want to know.

It's plain English.

>I've flirted with the idea of installing Linux on a
> spare box. Is this nonesense the kind of stuff I
>should expect?

Of course not. It's just a possible consequence associated with the complications of having the wide variety of packages with the huge number of possible combinations that Debian has. But that's a GOOD thing, even if it can be a little overwhelming. There are other distributions where choices are firmly made for you. I prefer one that lets me make choices. I can accept the potential consequence that my choices may make things a little more complex.

Initial installation on Debian, especially if you start with a live Debian-based distro like Knoppix or Ubuntu, is really quite easy. If you're starting from scratch on a spare box, it's super easy.

The only nonsense you shoud really *expect* are:

1. Be prepared to do some research on any wi-fi hardware, and try to find out in advance if you need NDISWrapper. This is one of my pet peeves,
since wireless networking is quite the killer app these days, and the community seems comfortable passing the buck.
2. It might not magically put your window manager at the resolution that you want. This shouldn't take more than a little googling to fix, but it can be annoying.
3. Audio, particularly if you plan to record audio, is a subsystem with its own issues. Audio playback tends to be much easier these days, but I'm into multitrack recording, making synthesizers, etc. It's pretty tough to follow, even with a lot of experience.
4. DVD video playback. Aggressively suppressed by the motion picture industry; community is rebellious enough to have useable players on the fringe, but remains willing to pass the buck. Perfectly understandable, but still quite a nuisance.
5. Laptop power management - I have yet to see it work well on a linux laptop. The latest Ubuntu's hibernate command just crashes my Toshiba. Power management is on the short list of really important features of a laptop. Maybe it can be made to work, but I have not managed it for years of trying.

I have a long, long list of annoyances with every system, so don't get me wrong here. I'm just trying to point out a few items that I can pretty much guarantee will get in your way at some point.
A lot of work is being done in all these areas, but some things like WiFi and DVD playback have some very solid showstoppers (like the threat of prison).

Re:How about just using a live-cd to do the update

[Professor_UNIX]

This makes me wonder why the upgrade process is being run under the target installation in the first place. How about upgrading the system off-line through a live-cd of some sort?

Because only extremely limited distributions would require you to take the machine offline to upgrade it. The Linux you're looking for is Red Hat or Mandrake. I need to be able to upgrade my Debian box from thousands of miles away... I'm sure as hell not going to fly out to a datacenter somewhere and reboot my box onto a bootable CD and run the upgrade. That's just silly.

We're All In It Together

[Doc Ruby]

This upgrade/dependency problem is the same, most important, problem Debian releases have throughout the cycle. Or at least, it's the same solution: a robust, easy installer. Not just a flexible installer that handles all the many combinations of hardware, software, network, and configurations, hiding the complexity under the hood of a simple GUI which allows configuration of every option. The installer must also detect failures, and report them back to the release managers. Of course this failure notice should be optional, but automating everything but the "OK/Later/Cancel" opt-in for messaging, and offering a tracking ticket# (even just pointing to the existing id#s of identified problems), will make the most of each cycle. Open source's greatest strength is the continuous real-world playtesting as the source evolves. We shouldn't have releases that fail more than the centrally-planned proprietary systems. We need to close the loop in our release process, with release tools as good a model of our distributed communication as are our development tools.

Tools and Libraries

[slapout]

installation tool apt depended heavily on the changing C++ libraries

If apt is that dependent on the libraries, maybe it should be staticly linked. I know static linking is usually considered a bad thing, but this is one case where an exception to the rule may be needed.

Serious Woody Breakage!

[AyeRoxor!]

No man wants to read these 3 words. I will be sure to steer clear!

Re:Is anyone surprised?

[nametaken]

The real frustrating part is that we wait YEARS for them to straighten this stuff out, figuring you're using the distro that takes the time to get it right, and avoiding headaches.

Now I have serious probs, and I'm wondering why I'm using Debian at all.

Re:Mixing Lilo and some kernel configs not nice ei

[Qzukk]

Not an easy task. You'd have to predict which drive letters the drives would be assigned, which would be a nightmare if you try to mix IDE and SATA and SCSI and USB drives (also on the SCSI subsystem) all in the same machine.

Perhaps detecting that you're currently installing on SATA and letting the user know they might want to double-check your drive assignment before rebooting would help, but it would still expect the user to know what the hell was going to happen next time the computer started.

I think this is one of the few times that disklabel would be of any use. (disklabel lets you "label" each partition, and refer to them by label in fstab and I *think* kernel's root= parameter instead of requiring you to know the device name, but there's no easy tools that understand it, and only a few filesystems support it)

No problems here!

[canadiangoose]

I've got a few Debian servers here at work, and a few at home. I read the release notes and warnings, updated my apt and proceeded into a dist-upgrade. All of my boxes upgraded without trouble. The only strange dependancy that I have noticed, is that Sarge is trying to replace Postfix with Exim!

Re:Is anyone surprised?

[Sinus0idal]

I'm not really surprised that there are problems upgrading from woody to sarge. Some of the packages used in woody for example probably don't even exist under the new tree. I know, for example, that those on woody are probably still using exim3, and sarge will use exim4. Except for very simple files, there is no automated and reliable way to upgrade exim3 conf files to exim4, so exim4 needs to be reconfigured manually. With such a large jump, I wouldn't really expect things to be 100% smooth to be honest.

huh? This is FUD?

[o-o]

Ummm. I have been using Debian for ages and never noticed. The author does not give any concrete pointers to errors encountered. He is though the go to person for people with upgrade problems. So I guess he is blowing a problem totally out of proportion. Someone should have stopped him from trolling on devel-announce.

Re:Is anyone surprised?

[Rei]

My problem with just using the official repositories is this: I don't upgrade if it's not broke. If there's no security problem, and it's working for me, I see no reason to upgrade to the latest stable. What I do use apt for is installing new applications that weren't part of the distro. Using the official repositories is generally pretty worthless for this, and I end up doing actions like this a couple times per month.

I've had it

[drwho]

I got bit by this stupidity -- took my main server offline for a day. Debian has really gone to hell lately. I am either going to switch to something else (Gentoo?) or maybe join if anyone wants to fork Debian into something that concentrates on quality.

I am just blowing off steam? I hope not. I hope that I can find something to replace Debian. Unfortunately I think that competancy is becoming rare. Who knows what disasters lurk in other distros.

Re:I've had it

[Ziviyr]

Gentoo is vastly worse in this department than Debian AFAIK.

Re:Cyclic Dependencies ?

[Erpo]

I've flirted with the idea of installing Linux on a spare box. Is this nonesense the kind of stuff I should expect?

Yes. Whenever something in Linux (and here I talking about all possible lumps of problem code surrounding the Linux kernel) doesn't work well by default, you'll find that on average the level of knowledge of Linux internals you'll need in order to solve the problem far exceeds what is required in windows. All in all, although Linux has made a lot of progress, it's still in pretty dismal shape when you want to perform certain desktop tasks.

Web browsing? Email? Photo and document editing? Most of the time that's no problem. Adequate, tolerable tools come installed by default. Changing the system configuration? Installing or upgrading software? Now you're in trouble. Most people run into Linux roadblocks when they try to push the limits of the OS so that it's as functional as windows.

Re:How to kill Debian

[runswithd6s]

Downgrade the troll above, please.

Re:How to kill Debian

[McSpew]

Downgrade the troll above, please.

Please do elaborate. How exactly was I trolling? I was speaking out of frustration as a Debian user, not as some asshat who likes to flame Debian. You, on the other hand, simply painted me as a troll, but couldn't be bothered to debunk any misconceptions you believe I'm propagating.

A hacker's upgrade...

[runswithd6s]

Getting a list of packages on debian and the instructions to dselect regarding that package:

dpkg --get-selections > oldlist

Do this before you upgrade. Likewise, if you want to compare files installed pre/post upgrade, make a backup copy of /var/lib/dpkg/info.

cp -rp /var/lib/dpkg/info /var/lib/dpkg/old-info

As per release instructions, upgrade apt first. Then:

apt-get dselect-upgrade
or
apt-get dist-upgrade

You may need to run apt-get install -f a few times, but apt will tell you when it's necessary. Too much typing? Get over it. Get a list of the resulting packages installed:

dpkg --get-selections > newlist

Compare them:

diff oldlist newlist

Now, to compare files installed per installed package, diff files from your saved /var/lib/dpkg/old-info.

for i in /var/lib/dpkg/info/*.files; do
echo "Comparing $i to old version"
diff $i ${i/info/old-info}
done

Essentially, the info is there for you to use. Debian is an evolving system, so one should learn where the data is and take advantage of that knowledge. Everything is in flat files, easily accessible, and parseable by standard UNIX tools. There are a plethora of useful packages and tools to examine your debian system: grep-dctrl, debian-goodies, apt-listchanges, debsig-verify, etc. For example, one tool that's often ignored is apt-cache. Try this some time:

apt-cache policy PACKAGENAME

Looking for an available package to download? Search the available list for a REGEX that matches descriptions or package names...

apt-cache search REGEX

Re:A hacker's upgrade...

[jrockway]

Stop being such an idiot. Debian doesn't have "patchlevels". OK? If you don't like it, don't use it! (And stop fucking whining about it!)

Debian is a set of constantly-changing packages. A lot of us like that, since we'd be updating these packages soon after release anyway. If you want an OS with a patch level, then use Windows and leave use alone, OK.

I like how debian is!

Re:A hacker's upgrade...

[Burz]

I *know* how Debian is. I run several. Debian doesn't have anything like patchlevels because it isn't an OS. Any mass of software that tries to encompass all possible services and apps as equals isn't an OS.

So why are Debian apologists dumping package-listing info on people when they ask a simple question that relates to virtually every OS that has ever existed? Are they too good (or stupid) to recognize the context of the question and say that the 'OS' itself cannot be distinctly identified and therefore cannot be 'patched' as a unit?

Re:A hacker's upgrade...

[jrockway]

The debian apologists are dumping package-listing info on you because they don't know what the hell you are asking. Patchlevel. What does that MEAN? Why do you care?

Re:How to kill Debian

[Gulthek]

No. You attempt to refute his valid points. Please.

Re:Cyclic Dependencies ?

[IpalindromeI]

I've flirted with the idea of installing Linux on a spare box. Is this nonesense the kind of stuff I should expect?

Do you have a reason to try Linux? Just from your tone you sound rather apprehensive of it in the first place. See if this describes you: "I'll just give it a shot so I can see why everyone is making such a stink about it. Then my condescending attitude will be justified because I actually did try it and didn't like it."

Frankly, even though you are obviously a "serious computer user" since you "create media" and "edit audio," if you don't have an idea of why you might want to switch to Linux, you aren't going to find a reason by just trying it out. What you'll probably find is that you can't figure out how to easily do the things you want to do in one afternoon. Or maybe you will, but they won't be any easier or wow-bang than just doing it in Windows. So you'll shrug your shoulders, wonder why everyone is making such a stink about it, and wipe the drive.

You should have a reason when you decide to do something, even if that reason is just to explore. If you were the exploring type, you would have already tried it, rather than just "flirted with the idea" of trying it, so that one is out. If you don't have another reason, you'll just be wasting your time. Honestly, it's the same with any decision in your life. Try thinking through things, rather than just randomly trying them because you know they exist.

i think its hilarious that all these people are ..

[Hohlraum]

basically admiting that they didn't RTFRN (RN == release notes). If you follow the release notes you are fine. They give you a few instructions and all the commands to use:

http://www.debian.org/releases/stable/i386/release -notes/ch-upgrading.en.html

personally I think its kinda gay that these package managers don't always just attempt to update themselves and their depends first. Or warn that new version of the package manager is available and ask to install it first. I think even up2date *gag* warns about that.

bold font

[cahiha]

don't read the freaking release notes, you will have problems

That's a bug with the software, not with the users.

Also, this breakage gives us a yet another reason to bash C++ as a poor excuse for a language

It's not C++'s fault, at best it's the fault of the compiler/ABI. Even C compilers have problems like this.

Re:How to kill Debian

[Aldric]

No. There are some very valid points made.

Re:How to kill Debian

[runswithd6s]

The subject of the parent is itself suspect of reasonable objectivity. How does one kill a highly successful distribution that is 100% driven by the community at large?

"Take freaking forever to freeze for a release." There were a number of mitigating issues regarding Sarge, not the least of which was creating a new installation suite modular enough to work on all 11 ported architectures (not two dozen). Few can claim more portability. The second largest hold-up was the lack of an autobuild infrastructure for security updates. This was exhaserbated by hardware failures of key buildd daemons, etc. Regardless, time between releases is a sore subject for Debian Developers as well as the users. It is well-discussed on the lists, and in the public archive. Feel free to search debian-release, debian-project, and debian-devel for the relavent discussions.

"Take freaking forever to ship after freezing." I'm not actually sure what was meant by this. The freeze was done in steps, and once the actual freeze was announced, the release happened blazingly fast by most standards. However, this is subjective to POV.

"Ship a broken upgrade even after all the damn testing." How did Debian ship a "broken upgrade?" It created a few ISO images with a typo in /etc/apt/sources.list which prevented updates from an archive that contained no packages yet. What was broken? Additionally, published release notes and detailed installation instructions outlined the difficulties you might find during an upgrade from woody to sarge. What known breakages were hidden from view? What malicious intent did Debian have?

Seriously, to use your phrasology, the above post is nothing more than flamebait. If you don't like Debian's release cycle, either roll up your sleeves and participate in the process to improve it, or jump ship and use something like Ubuntu. Debian is not dead, is not in danger of dying, and could benefit more from helpful contributions than rants about its shortcomings.

I have failed in these posts by feeding the troll. I haven't provided a new defense or pointed out new facts. All of this information is available for those that would search (with little effort, mind you) for it. Happy hacking, and happy feeding.

Re:How to kill Debian

[jhoger]

Debian is the universal free software distribution.

If they killed off the architectures that you happen not to care about, it wouldn't be universal, so it wouldn't be Debian. It's not a waste of time, it's what the project is all about.

Frankly, apt works great on a day-to-day basis. And apt-get dist-upgrade appeared to work fine for my Woody web server.

If you want a slick x86 only distribution, look elsewhere. I'm sticking with Debian because they do things right. And where there are problems, I'm convinced they will fix them in a way that is ultimately scalable.

-- John.

Re:How to kill Debian

[sublimespot]

I consider your points trolling. How you got +5 Insightful is beyond me.

Your first and second points are basically complaining how long it took to get out the door. Who cares? If you are not helping fix bugs then dont complain that it is taking too long to get them fixed.

All my servers run Debian stable and I love the fact that the release takes forever. This keeps the server maintainable. The configuration files never need updating because the software versions never change (except for security fixes). The servers have all been rock solid for years.

If you want a more current release run "unstable" (which is quite stable and I run on my desktop and laptop). From your comments I conclude that you shouldnt be using stable. You dont understand what its for.

Your last point - ship a broken upgrade after all the testing. My rebuttal is very simple - you didnt read the release notes. I did. All my servers were upgraded without issues.

Re:Yes

[njcoder]

I installed Sarge on an old laptop that used to run Woody (and ubunty for a couple of days). Both Ubuntu and Sarge booted up very slow. Kept getting DMA errors on boot. I mainly use that laptop to surf the web and as a vnc client to other desktops and servers. It's a really slow machine. I wound up just downloading a Damn Small Linux ISO that I boot from the cdrive. It boots up much faster and has a vnc viewer in it. Obviously not a solution for everyone but DSL made things a lot easier for me.

There is no core OS

[Burz]

So how can you manage a patchlevel with no defined core?

How far do you go in applying patches? Do you include apache and PHP... er what about cdrecord and K3B? People rely on those last 2 for data archiving sometimes. Do you update the browser... and which ones?? Oh heck, might as well include fixes to KStars and Audacity.

Or maybe not. Or maybe we'll update K3B in the 3.1.05 patchlevel, but not include newer fixes in our 3.1.08 patchlevel.

There is no line drawn between OS and additional services and apps. So the average user is screwed.

don't upgrade in place if you can help it

[cahiha]

If you really care about a system and minimal downtime due to upgrades, have two root partitions (it's only an extra 5-10G). Instead of upgrading, you make a clean install on the unused root partition. Clean installs generally work better to begin with, and you have the old install both mounted and bootable to figure out any problems and copy over configuration files.

As for complaints about this sort of thing, I still prefer Debian. I just spent several hours upgrading an OS X system from Jaguar to Tiger. A trivial file system inconsistency in HFS caused the installer to crash reproducibly and eventually required me to manually patch inodes (apparently a fairly common problem on Macintosh). And I'll have to wipe a Windows machine clean tomorrow because mysteriously hardware has stopped working and no amount of fiddling will do.

In comparison, these Debian upgrade woes seem minor. And unlike the Mac and Windows problems, the Debian upgrade problems will generally fix themselves after a few days when the package maintainers catch up.

Upgraded remotely without a hitch

[garethw]

After perusing the release notes and understanding the apt issue, I bit the bullet and went ahead with a full upgrade of a server to which I will not have console access for 2 weeks.

The entire process was smooth - 400 packages upgraded, and 60 or 70 new ones.

I wouldn't have dared do it with any other distro.

Thanks, Debian.

Mod parent Up please

[Burz]

Thank you

Not so bad considering...

[MobyTurbo]

Actually, although one would wish it were better, the fact is that 70% of users from a distribution of 2002 upgraded to a 2005 distro release without *any* problems. Try that with nearly any other Linux distribution and you'll get at least some breakage, even if the versions are only six months or a year apart.

The main surprise is that Debian usually doesn't have any problems with a dist-upgrade and that now it needs a bit more care, not that this particularly wasn't done well comparitavely speaking.

OT: rankings

[runswithd6s]

He was only moderated up 3 points (1 because he didn't post anonymously). At least some of his rating was flamebait. You probably have a +1 bonus for insightful. Downgrade that to 0 if you don't want unwarranted inflation. I find that most "insightful" rankings are overrated anyway and better classified as either "informational" or "interesting" (perhaps).

Static linking considered harmful

[cortana]

Never link to glibc statically.

Re:How to kill Debian

[dvdeug]

those folks need to get their heads out of their asses. They need to stop wasting time trying to officially support the two dozen or so architectures nobody gives a damn about, stop engaging in wars about whether non-free belongs in Debian, and concentrate on releasing something that's reasonably current and also supported by security updates.

So basically forget everything that makes Debian different from everyone else. We aren't going to give up our principles because some obscene idiot curses at us.

Standard Debian troll

[cortana]

Woody shipped with 2.2 by default, 2.4 was an apt-get install away
Sarge ships with 2.4 by default, 2.6 is an aptitude install away

This is a valid question, NOT a troll.

[Burz]

I suggest you read the thread for comprehension for modding it.

Look ma..

[pimpsoftcom]

I can tell the future! I called it. You all should have listened!

OS Patch Level == Dead Concept

[runswithd6s]

And the concept of an OS patch level is foreign to Linux and BSD distributions alike. For all the meaning you might derive from a version number, look at /etc/debian_version. If by OS patch level, you mean a list of possible packages to install and their associated versions, then those are found in a simple text file called Packages in a directory on the archives you request in /etc/apt/sources.list. This file is used to compare the versions of packages installed and packages available. If multiple versions are available, the decision about which version to install is configured in /etc/apt/preferences. It's quite flexible and distributed, perhaps a concept lost on Commercial UNIXes.

So, within the context of Debian, an OS patch level is an active comparison between that which is installed and that which is available. "apt-get install -u" will list the packages that can be updated from the archives you choose to track. "apt-cache policy PACKAGENAME" will give you detail about how available packages are assigned pinning priority, info you can use to see where the package will ultimately be installed from before ever running "apt-get install PACKAGE".

Really, OS Patch Level is a dead concept. My OS patch level is Debian 3.1 with the latest security patches pulled from the security.debian.org archive and a custom kernel...

Re:How to kill Debian

[wsapplegate]

Okay, I *know* I'm feeding the troll, but whatever, I just can't refrain myself...

> How to kill Debian in five ("Three, sir!") easy steps:

How to troll about Debian in three easy steps :

>* Take freaking forever to freeze a release.

* Ignore the fact that Testing was usable (and used) all along. Hell, I've got a *dozen* of servers running Testing since a few years, and you know what, I've had very few problems with them (in contrast, the Mandrake servers kept being broken, especially on upgrades)

>* Take freaking forever to ship after freezing.

* Inflate everything for FUD purposes and call "barely a month", "freaking forever"

>* Ship a broken upgrade even after all the damn testing.

* In the same spirit, call "some problems if you didn't RTFM", "a broken upgrade"

> Seriously, WTF? I like Debian, but those folks need to get their heads out of their asses.

* Insult the FOSS developers that bring you the software you run for free

> They need to stop wasting time trying to officially support the two dozen or so architectures nobody gives a damn about

* Give stupid advice about how volunteers should spend the time they donate to a project ; also shit on people who happen not to have the same setup as you (if you keep doing this long enough, you eventually morph into an eWeek columnist and proceed to write moronic articles where you explain to "the Linux community" that they need to drop every desktop environment but KDE to compete with Microsoft and Apple)

> stop engaging in wars about whether non-free belongs in Debian

* Clearly show that you don't give a damn about those wacky "Open Source" and "Free Software" concepts, and that you just want more warez, quick !

> and concentrate on releasing something that's reasonably current and also supported by security updates.

* Demonstrate to the world you don't know how to read security.d.o and use the information to backport the fixes into your packages. As an added bonus, show that you're unaware of recent projects

> Oh, and it would be nice if doing an 'apt-get dist-upgrade' didn't break things.

* Finally, make sure everyone understands you didn't look at the release notes for your distro before upgrading, since, as we all know, manuals are for losers

If you closely follow all the steps graciously demonstrated by the parent poster, your Debian trolls will have the most impact. For added points, you could also make some reference to "Debian stale" and/or launch the installer in expert mode, then claim it's difficult to install Debian. There is no limit to the FUD, really.

good points and...

[zogger]

...bad points. Yes, I understand the massive upgrade patch theory. It doesn't have to be that way though, there could be a hybrid middle ware solution that uses dynamic linking with advanced permissions just to change the individual files inside the various apps. a patch only but no running link thingee.

Most of the time there's no outright need to DL the entire app if it's a unixy design with files you would think (at least this rookie thinks that's how it's supposed to be). And with static apps, you can pick and chose which of the now vulnerable apps to keep online with, and to set your permissions corectly, patch those first, then patch the others at your leisure. That's the promise of stuff like xen combined with static compiling.

Anyway, it certainly hasn't hurt apple that I can see. Sometimes the old ways are good, sometimes it's better to admit progress marches on and that the new tradeoffs are worth it. The way linux is now it's a big problem with non compataible package managers and one dynamic link can screw over your whole system. Whyfor do I want that again? I'd rather have it so that I could choose my priorities over "OMG everything is now screwed and you are vulnerable from 16 directions" or "ignore it and take a chance". That's the two choices you have now with bug du jour/dynamic linking and absolutely no standard way for linux packaging. It *sucks*. You can even see it just within the so called debain distro family, allegedly all "debian" yet dozens of ways to do things, yet a vuln can hose a buncha systems and the patches can be quite different because of minute arcane differences in the way they got put together. Now expand that to all the various distros and methods. It's inefficient and buggy to begin with, then it goes downhill from there. Cool thinking 20 years ago no doubt...

There has to be a better way. Full release upgrades suck,why are they even needed??? You should be able to incrementally upgrade in perpetuity, incompatability with app packages sucks the big 1, having a plethora of apps go from working to vulnerable because of one bug in one file in one app/library sucks. It's OK if the fix is that small, but it shouldn't make everything you want to run go useless instantly, that's the major problem, especially for systems that need to stay online 24/7.

No, no DSL yet, currently I just upgrade crap overnight, or that's when I DL mini distros or big apps. Dialup is still a helluva lot better than "no intarweb", heh.

Anyway, I sorta kept track over the past year, the vast majority of security updates I had to patch really wouldn't have effected me much if at all. And I bet it applies to 99% of the computing public, and the other 1% gets paid to dork with that stuff, so it's job security. I don't see a problem with it going to static compiled then. RAM cheap-check. disk space cheap-check. Ability to stick your stuff wherever the heck you want to, double check. if the patch was limited to just the actual fixes and not the whole app, no biggee. DL the files in some sort of permission jail for the patching aspects.

Anyway, something is got to give on this scene, it's gotten beyond outta hand.

IMO, YMMV, IATOOMA (I am talking out of my....) anyway... %^)

h8 debian

[bonezed]

had so many issues at work with Sarge, probably due to the regular dist-upgrades

I wish I could use something better (like Slackware), but work insists on Debian

Re:i think its hilarious that all these people are

[craigevil]

Read and Follow the install/upgrade instructions and you will have few to no problems. Upgraded 6 servers and 10 desktops all without any glitchs. Other than having to change the /etc/apt/sources.list A mix of Testing and Unstable is the way to go for a desktop or laptop. Debian ROCKS.

Breakage, feh

[WWWWolf]

There's always been "breakage" when moving from major to major. Not as bad as anything mentioned in the article, but still, it's never completely simple. It's gotten even better since apt-get...

Most of it having to do with me needing to manually somehow convince the system to install new Perl and everything it depends on.

And I think the worst thing I've ever have needed to do was to manually de-archive, edit install script, and re-archive some package (I think it was modutils, or some other kernel thing) because I had neglegted to move from 2.0 to 2.2 kernel (why? it worked...) in the previous version and leap from 2.0 to 2.4 was just too corny for the package installer to try.

But I've never managed to break anything too badly even with ocassional --forcing... =)

my "joe sixpack" observation

[louden obscure]

i dunno about stable, but i have had pretty good luck with my sid desktop (many months of no serious breakage)by only upgrading after 6:00 PM CST and only on Sunday evenings.

Re:Cyclic Dependencies ?

[VividU]

Interesting reply. You make some good points. A bit condescending but still there are the kernels of some good debate in there.

For the record though, I have installed and used Linux. I've also installed and used BeOS, MAC OS 1 through X, MS-DOS through XP Pro and the OS's of my Apple //e, various Atari's, TI's & the TRS-80. I've done my share of exploring.

I should have been clearer in my original post though. I meant "flirting with Linux" in a professional context.

So while you put condescending quotes around my work ("create media", "edit audio") you should realize that it's one thing to this work as a hobbyist and a wholly different thing to so as a pro.

Your post intrigued me though. Your right, I should have a reason for switching to Linux (professionally, that is). But your post seems to imply that there is no good, compelling reason to do so.

So my question to you is this: What compelling, technical, pragmatic, real-world reason do I have for switching from Windows to Linux?

Best Regards,
VividU

Re:Yes, Linux is great.

[polysylabic psudonym]

When I upgraded from Debian Woody to Sarge I had to fix my mail server daemon. It took 2 hours. When I last upgraded a Windows machine - 98 to XP - I had to throw away a scanner, mothball a printer and bid a fond farewell to several games. The games and printer became useful again after a few months when the manufacturers got around to releasing an XP patch.

Re:Cyclic Dependencies ?

[oldosadmin]

I think that the gp's point was this:

If you have to ask what the reason is, you don't have one.

Re:Cyclic Dependencies ?

[VividU]

" I think that the gp's point was this:
If you have to ask what the reason is, you don't have one."

Although I understand and appreciate the spirit of your reply, it is a bit of a cop-out.

You mean to say that there is no compelling reason - one that stands on it own, to switch to a Linux desktop?

Lets take the point further - what reasons are there to switch to a Linux desktop (besides geeky fun)?

Re:Cyclic Dependencies ?

[IpalindromeI]

A bit condescending but still there are the kernels of some good debate in there.

Like begets like, but I regret giving in to that temptation, for the tone obscured my intent. My purpose was not to start a debate of any sort. I have no interest in whether you use Windows or Linux. My point was that you seemed to have no interest in it, so why worry about it?

Your post intrigued me though. Your right, I should have a reason for switching to Linux (professionally, that is). But your post seems to imply that there is no good, compelling reason to do so.

So my question to you is this: What compelling, technical, pragmatic, real-world reason do I have for switching from Windows to Linux?

I am not trying to persuade you. There are many reasons to use Linux, and there are many reasons to use Windows; there's more than enough information available to determine them for yourself. I'm trying to help you realize that you need to determine them before you do an evaluation. Otherwise, you won't have any criteria to judge it against, and the evaluation will be a waste of your time. If you can't come up with any good reasons, that's an indication that you probably won't find Linux useful.

On a side note, the condescending quotation marks were a poor attempt to point out that those remarks did not help your statement. When your first sentences are used to establish "street cred," (eg. "I'm a serious computer user."), it signals to the audience that you are uncertain about your position and posteuring to make it seem more forceful. In reality what it does is make you look foolish. Those who are knowledgeable will be able to determine your level of expertise from context; trying to point it out to them will mark you as a fraud. Those who are not knowledgeable might believe you, but their opinion doesn't matter anyway because they don't know what you're talking about. It was a critique of the method of communication, not the content of the message.

Better than Windows

[RedHatRebel0]

Upgrading a Linux distro, no matter which of the main distros it is, is not anywhere as problematic as a Windows upgrade. I am dreading when my friends & family start calling for me to upgrade them to Longhorn in a few years from Windows 98/ME/XP. I'm glad I'm using Debian. If you follow the release notes, you won't have any problems...