Slashdot Mirror
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."
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.
Javascript + Nintendo DSi = DSiCade
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
Haida Manga
Everything is falling apart. You may experience some discomfort. Just thought we would let you know. have a nice day.
Starsucks
Obviously this was a rushed job. Typical Debian, always cutting corners, never taking the time to do things properly :P.
Any reason why I should switch from Ubuntu to Debian?
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,
Tharkban (It is a signature after all)
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.
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!
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
I have discovered a truly remarkable proof for my post which this sig is too small to contain.
My brain exploded trying to parse this sentence.
;-)
And we wonder why we aren't taken seriously by management.
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.
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.
This is, after all, Debian
"We are all geniuses when we dream"
- E.M. Cioran
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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
If I have been able to see further than others, it is because I bought a pair of binoculars.
He's using SATA and the newer linux kernels moved SATA from IDE to the SCSI subsystem.
/dev/hd* and his lilo root=/dev/hd* lines became wrong.
So all his fstab entries using
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
2*3*3*3*3*11*251
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).
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.
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).
>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).
-fb Everything not expressly forbidden is now mandatory.
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:
- You link everything statically, or
- 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!--
Promoting critical thinking since 1994.
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.
--
Promoting critical thinking since 1994.
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.
assert(expired(knowledge));
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.
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.
(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.
Javascript + Nintendo DSi = DSiCade