Howto: Set up and Maintain a Mixed Testing/Unstable System

[cb474]

Thanks for the lengthy explanation. I've being using "aptitude dist-upgrade", but you're saying "full-upgrade" is the same thing? Is there any difference between the two?

Also, just so I'm clear, is there a problem if I've started using aptitude and then I use apt for something? Not that I would, given your explanation, but I think I already have done this a little and I'm just wondering if it's going to mess aptitude up in some way.

[Eck]

No, it shouldn't mess it up but if removing one of those programs later then it'll just remove the program itself and unused dependencies. You might want to check the aptitude show for those packages you used apt-get for and see if the recommends, if any, listed there are installed on your system as apt-get (at least before the very latest apt-get) did not install those. But in general for the future if you're going to want to take advantage of aptitude then you should use it alone.

There is no difference between dist-upgrade and full-upgrade. It's just that the newer versions of aptitude now use safe-upgrade instead of upgrade and full-upgrade instead of dist-upgrade. To take into account users who haven't caught on to this yet, they have aptitude answer to either term appropriately.

I've read that apt has been updated to also install recommends automatically by default. Not sure whether that has reached Lenny yet. Still, it does not keep track of automatically installed packages so it can remove those when you uninstall the main package like aptitude does.

When I install something I usually check out the package I want with aptitude show so I can write down any suggested packages it lists. I may or may not want those so it gives me a chance to look those up for myself and make a decision about them. I nearly always want the recommended packages so I've been happy that aptitude has always taken care of those automatically for me.

Sometimes some of the recommended packages in the lists are old versions of things that have replacements and so aptitude will either say it is not installing them because in Debian something like that would be a conflict if the package was prepared correctly, and these types of things are handled automatically quite nicely, OR it will be confused because the packages have a boo boo and do not list conflicts. In that case, nicely too, aptitude will start its attempts to resolve the dependencies and you can see printed out just what packages are causing the problems. You can then quit out of the install and aptitude show the various packages and in general it will be obvious to you as to which packages to keep and which look older and so can be replaced. Sometimes just installing the newer one and removing the older one will then let you go ahead and aptitude install the original package you wanted and this time aptitude will not have a problem with it.

So, some things are automatic and some aren't, but it's pretty easy to stop what's going on if it doesn't quite look right and fix things up by taking a look at the packages aptitude was listing.

The GUI tools usually do not give as much info, and when they go ahead and automatically try to install things and they wind up partially installed with some obscure errors listed, you will curse yourself for not using the less pretty but more descriptive and user interactive aptitude.

Basically, just getting used to playing with aptitude from the command line will enable you to stop problem installs before proceeding, give you an understanding of how to make things right, and keep your system stable and without half installed, broken packages lying about.

The only thing similar I've seen is OpenSUSE's YaST Software Management from the qt interface (not the new GTK interface which offers less information and so more potential to get a damaged system). Folks sometimes don't like it because it is slow, however I have found it to have similar capabilities in resolving potential hiccups as does Debian's aptitude. And all that from a pretty GUI too!

It has nice stuff, sort of like aptitude on steroids. For example, I can use an older version of something if it has had an Online Update fix for it whereas a newer version hasn't. I can choose an older version from a 3rd party repo that includes extra multimedia codecs I desire whereas the newer version does not. So I can selectively upgrade package for package. Kinda neat! No other GUI package manager can do the things YaST can.

Smart can wreck a system doing upgrades automatically, whereas YaST can be fully user controlled and have problem packages skipped, staying with the versions the rest of the system doesn't conflict with, and the remainder upgraded. When the rest of the system gets the upgrades needed to make the problem packages work, then there will no longer be a YaST resolver complaint and the user can proceed to upgrade those as well.

Unfortunately, it really takes a user to explore into both Aptitude and YaST to discover neat system saving devices such as these. They are not things that can be listed step by step in guides. It is part of the learning process in Linux. So, the best advice for a new user is to stick with what is known to be stable. In Debian that is Etch, in SUSE that is 10.3 without adding zillions of repositories (like me, but I like new stuff and know my way around to keep things stable, I hope). The less upgrading, the less chance of messing up a good thing.

As long as this stuff looks confusing, that means it is something one shouldn't be doing if they want to keep their systems running smoothly. Once this technical jargon looks like it makes sense, then more risks taken will be successful because one will understand how to deal with situations that come up. An experienced user will be able to deal with strange things that come up in a few minutes. He understands the tools to use and how to go about using them. A new user is probably better off avoiding the latest untried software versions until such time as fixing things will only take a few minutes. Any longer and then one isn't using their computers, the computer is taking up time with busy work instead of getting real work (or play) done.

That's why, since we're talking Debian here, I would say that a new Linux user would probably be happier with their Debian experience by running the officially released Etch, at least at first while they are learning about the various tools and software. Very little upgrades to be concerned about. Those that are available are important for security or fix important bugs. One can watch the tools in action and learn their way around.

Yeah, Lenny is better once one is at home in Debian because new software versions and new software to Linux bring some nice new features along with them. Usually all this appears in Lenny within weeks after being released upstream, after a period of trial while in Sid. So we keep up with the Jones's better. But it's testing, so occasionally hiccups will occur. Better to be a bit experienced in dealing with hiccups before barging in.

But wait. Other distro's get these new versions quicker so doesn't that make them better? The answer is no, because their users get all the bugs that haven't been fixed yet, need to research work arounds to use until updates and fixes are figured out and released by the distro, and sometimes these things aren't fixed until 6 months go by and a new distro version comes out. In Debian, with it's rolling releases, as soon as a fix works we get it. No more work around needed and Lenny grows towards its ultimate goal of being the next official Debian stable release. Fun to watch it grow! But frustrating if things break on the way, especially to someone who needs to take all day to fix things only because they don't understand the Debian tools available yet.

Okay, I'll shut up now. Did I mention I tend to ramble? Sorry, but I hope some of that helps!

[rickh]

Hmmm! Interesting. It appears that this post made the Debian News; but the link goes off to somebody's blog rather than here. I tried but couldn't find the blog they're linking to.

[Telemachus]

Hmmm! Interesting. It appears that this post made the Debian News; but the link goes off to somebody's blog rather than here. I tried but couldn't find the blog they're linking to.

Yup, that's ****** annoying. First, you are told that you need to log into WordPress. I have a WP account, so I logged in. However, the blog that the page refers to doesn't seem to exist. (I tried the exact address of the link as well as a few shorter versions, trying to find the top-level directory. No luck.) If I were you, I would email the person who posted the link on Debian news (cj2003@debian-news.net) and ask him to fix the link. He seems to be the "webmaster" for Debian news, so it shouldn't be much trouble. The link should point here (which anyone can read without a registration) rather than to a password-protected, non-existent blog.

[cb474]

I find that with this mixed system setup sometimes aptitude wants to do kooky things. For example, currently I only have deluge and vlc installed from unstable. But today on a full-upgrade, aptitude wanted to install a version of evolution-webcal that conflicted with the current version of evolution, so it's solution was to remove evolution and as one possible other solution aptitude even suggested removing gnome-desktop-environment.

What gives? It's like because some package has been put in testing that doesn't work with other existing packages, aptitude just wants to totally break everything related to that package. Why doesn't aptitude suggest upgrading evolution to unstable, which would at least not just break and remove all kinds of packages that you're using? In the end, it seems like manually upgrading to the unstable version of the central package in question is the solution that makes "aptitude full-upgrade" happy, but aptitude never suggets that itself.

Or I've also seen aptitude suggest upgrading a package to unstable as a solution, but then when I hit "Y" accept this solution, it doesn't do it. It just skips over the package.

I just find it confusing. And why would a version of evolution-webcal show up in testing, anyway, that is dependent on packages in unstable? Am I missing something about how all this works?

[rickh]

I have neither deluge nor vlc installed on my mixed system, but I do know that it's sometimes surprising what comes with packages that you didn't realize.

Have you been using ...
# apt-show-versions | grep unstable
... to keep track of exactly what you have from Sid?

Aptitude periodically offers me dependencies from experimental or Sid because those repos are in my sources.list file. If you ask to install a program that doesn't exist in your default release, aptitude will install it from a different one with hardly any warning.

[cb474]

Yes, I've been using apt-show-versions, which is very helpful. And it was a very short list of things.

The thing that was strange to me here was that it involved evolution, which I definitely did not have installed from unstable. But with a full-upgrade, aptitude wanted to install a version of evolution-webcal that was only compatible with other unstable verisons of other evolution packages (including the main evolution package itself). That didn't really make sense to me.

[rickh]

Don't really have an answer, but it may be related to evolution-data-server, a dependency for many programs. Is that among your "unstable" programs?

[cb474]

No, the only thing in my unstable programs was vlc and a couple lib packages related to vlc (I guess deluge-torrent has been kicked down to testing and no longer shows up as unstable).

I ended up upgrading to the unstable version of evolution, to make aptitude happy. Even now with the unstable version of evolution, evolution-data-server is not listed as one of my unstable packages.

[alidh]

I've both the repros from lenny and sid in my sources.list.

And have: APT::Default-Release "testing";

Can I do

Code: Select all

aptitude dist-upgrade

, without upgrading my whole system to Sid?

And is: APT::Default-Release "testing"; also working for aptitude?


btw: thanks for this howto

edit: I'm working a lot with music prog. like jack and ardour. Should I install those packages from lenny or Sid?

[rickh]

I've both the repros from lenny and sid in my sources.list.

And have: APT::Default-Release "testing";

Can I do

Code: Select all

aptitude dist-upgrade

, without upgrading my whole system to Sid?

And is: APT::Default-Release "testing"; also working for aptitude?


btw: thanks for this howto

edit: I'm working a lot with music prog. like jack and ardour. Should I install those packages from lenny or Sid?

Yes, and yes. "aptitude dist-upgrade" is deprecated in favor of "aptitude full-upgrade"; and "aptitude upgrade" by "aptitude safe-upgrade". The old ones still work, but you might as well start using the new ones.

Aptitude will auto-magically know whether the specific packages should be installed from Lenny or Sid.

[alidh]

Is it possible to have automatically (using aptitude safe-upgrade for example) from some packages always the newest (unstable) version?

[rickh]

I suppose you could set up a crontab as root to run aptitude upgrade <packagename> every day at midnight or something, but you'd have to set flags to auto answer "Yes," ... probably not a good idea with Sid packages.

[hkoster1]

Nice essay, rickh! Any thoughts on reverting from Sid to mixed testing/unstable using your method? I guess it would (without any -t unstable installs) take a while before it had become 100% testing...

[rickh]

...reverting from Sid to mixed testing/unstable...

It shouldn't take much effort to get back to "mostly" testing if you used Aptitude for the original installations. Since "aptitude remove" takes all the dependencies along, you won't be left with lots of problematic orphaned libraries, etc.

You don't need to worry about packages that have the same version in Lenny and Sid, which is probably more than half.

Change apt.conf to default to Testing ... aptitude update ... apt-show-versions | grep unstable ... then review the identified packages ... aptitude remove, then aptitude install any you want downgraded.

The biggest problem you're likely to encounter is the massive replacements you'll get if you originally installed very large metapackages, like "gnome" or "kde" from Sid.