Brad Ideas - upgrading - Comments

Linux needs to be easier than Microsoft Windows Operating Sys...

Francisco — Fri, 30 Mar 2007 23:58:07 -0700

Hi.

On Microsoft windows operating system you just install a new program and there is no a need to worry what dependencies you will need because the installer already have those DLL's (Dinamic Link Libraries) which are dependent for the new program already included within the installer it self and the installer automatically copies these DLL's to the %windir%\system32 folder. Why cant it be the same for linux, why cant it be all this easy for installing new programs, a linux program installer (the RPM's or DEB's) should automatically satisfy any dependencies for the said program to be installed and not having to gun down the responsibility towards the users in having to download all these dependencies on the internet. That way no one would be interested in switching to Linux from Windows XP, its just way too complicated for the average joe.

>>>LINUX NEEDS TO BE SIMPLIFIED TO THE POINT IT IS EASIER TO RUN AND MAINTAIN THAN MICROSOFT WINDOWS OPERATING SYSTEMS<<<

finally someone with the same problem :)

David — Sun, 18 Mar 2007 07:12:18 -0700

Thanks for your article. It's hard to find articles that go as deep in the dependency problem. For the moment I'm having this problem. I want to run kdenlive on kubuntu breezy. And I found there is no proper way to do it for a non technical linux user as I am. No breezy package in the backports and the klikable package (http://klik.atekon.de/)does not run on my system because it can't find an rpm on the packmanrepository. Sometimes I think I'm the only one who run a linuxdistribution longer than 1 year :)...and run their system with a minimum of updates because I don't have a broadband internetconnection.

I do use apt

brad — Sat, 09 Dec 2006 18:42:32 -0800

In fact, I even use it on Fedora as well as Debian and Ubuntu.

The problem, as I noted, is that new packages are tested and built only with very recent versions of their dependencies. So, in order to try out a cool new program or to get an updated version of a program I use which has bug fixes or new features, I must also get new versions of all the dependencies.

And worse than that, these new versions simply aren't made available in binary forms for releases that are just a year old in many cases. Debian, for example, as stable, testing and unstable. But in reality, unless you want no ability to install new software, you have to run unstable. Now unstable is not nearly so unstable as the name suggests -- but this is still stupid. The truth is these new software packages you want to run don't really depend on all these new libraries and tools, that's just what the guy who built the DEB or RPM file had on his system at the time.

Running a stable system with older, more tested base packages is not an invalid goal. But it shouldn't prohibit you from running new software that doesn't actually and truly need something more modern.

Again, compare it to the Windows user running 7 year old Windows 2000 and having done one update to SP2. They can download and install almost every piece of Windows software out there. Try to run a 3 year old linux and you can't even get close to that.

Solutions...

Michael Kohne — Sat, 09 Dec 2006 13:00:38 -0800

Anonymous: The problem isn't just the packages that are distributed. Yes, regular updates to all the packages keeps the distribution up to date, but then you have touch broken configs regularly.

I believe there are two major points that Brad is trying to solve:
1) Configuration. Some packages can only be configured by modifying the config file that comes with the package. When you install a new version of the package, your config can be lost. This is broken, and I think the very simple solution of not making the user put their changes into the distribution config file is probably the best possible first to finally fixing this.

2) Dependancy. Not every package in the world is distributed through a package manager or has proper dependancies. Especially with software that one compiles oneself, the package manager is usually out of the loop, and thus, I can easily find myself with important software that 'suddenly' is broken. As Brad has noted, this is a MAJOR pain in the posterior, and doesn't do anything to help the image of Linux, or to get us away from dependancy on M$.

One thing I'm curious about: What do the Linspire folks do? Do they simply assume that you won't run anything that didn't come from them? Since all the packages would come through them, that would at least make it theoretically possible for all the packages to be correct. Do they have a real solution for config files?

Brad, thanks for getting a conversation going on this topic. I'm not currently using Linux daily, in part because maintaining the damn thing became more effort that it was worth to me.

Apt/Yum?

Anonymous — Sat, 09 Dec 2006 07:37:27 -0800

Neither apt nor yum (depending on whether your maintenance architecture uses .deb or .rpm files) suffers from dependency problems.

A given repository may not show a complete set of updates at a given time, which will cause either tool to reject the updates as incomplete (missing dependencies). This is not a problem - it's the correct decision! Once the repositories show a stable complete set of updates, they will be applied.

I've been running regular maintenance on many systems for many years, and have not experienced a problem. Understanding why maintenance updates are being rejected is the key.

There are some tools that can make incremental updates easier. for example, for yum there are a set of plugins:

yum install yum-fastestmirror yum-skip-broken yum-utils

You can then add the option '--ignore-broken' to your yum commands, and yum will try to apply as many dependency complete updates as possible (instead of giving up when encountering a missing dependency).

You can also periodically run:

package-cleanup --oldkernels --count=3

This will keep the latest three kernels, cleaning up the old ones (and dependent packages).

In short, the key to using apt or yum is regularly scheduled maintenance, and proper use of the included toolset. This causes small, incremental and easily managed changes to be applied to the systems. Trying to apply huge changesets, like a service pak, is where you will run into grief (and major system impact).