Well, I whipped out my trusty test machine, and decided to test myth versus reality, on an old sidux chaos install, that's been upgraded steadily. Last upgrade was maybe 3 or 4 weeks ago.

First I installed aptitude:

then, having had some experience now, I ran a test upgrade to see what files the system would remove. To make sure I had a record of these packages, I also ran it this way:


after it writes the data to the file, I ctrl + c to kill aptitude, and then take a look at what it wants to do:



Naturally, I reset smxi to run with aptitude, by opening up /etc/smxi.conf and adding this line:



Then I left X, and ran the actual dist-upgrade, with the results I posted above. For the record, libg2c0 has been replaced by libg20, and lapack seems to have been replaced with a set of new packages, it's some math thing.

And that's all it took to convert. To make sure, I might explicitly use aptitude to reinstall some of my core packages, but overall, the conversion was about as clean and simple as you could hope for.

To be on the safe side, I also installed the kernel after the dist-upgrade, to avoid any possible problems.

So that's about it.

If you want to avoid the forced package upgrade, use aptitude upgrade (that option is also in smxi misc tweaks, advanced tweaks, I'm not sure if you see it for sidux users though, I'll double check that.

This test confirms what hubi noted, and was something of a surprise to me.

After this, I ran the smxi cleanup cruft remover, which removes all leftover package ( dpkg -l | grep ^rc ) configs, most of those were from the removed ones above, using purge on the list would have saved me that step, but I wanted to be careful.

From now on, I'm going to do all future testing with aptitude, and after a month or so, I'll switch my last machine to use it too, with sidux, until I reinstall that.

Still to come, hubi's initial reports with his aptitude tests, which show the same excellent behaviors.
Back to top

I just tried this on my sid/sidux AMD64 blend which is about 9 months old and uses slh kernels and Nvidia proprietary driver and gets upgraded with smxi weekly. There are few bits of non-sidux approved stuff that have crept their way into the installation by various means, which I thought might cause some problems.

Anyway my experience pretty much mirrored yours, I was initially shocked by all the removals, but said what the heck and gave it a chance and smxi completed all successfully including a kernel update and reload of the Nvidia driver.

A further listing of suggested but not installed packages and the ability to pick and choose would be a nice addition, but perhaps a bit much to ask for. I made out OK with a pen and paper to check anything that looked of interest.

It all seems to be working fine thus far. :-)

UncleVom
Back to top

I believe whatever issues that existed in aptitude have been long since resolved, and any that might need work, are being improved more and more as time goes by.

To find the list of recommends, I think there's an aptitude command, read the aptitude links and information thread for more details.

That thread is the result of the initial aptitude research I did when I was working on the first smxi apt-get/aptitude abstraction routines.

One point I should make clear here: because sidux is still not supporting aptitude, anyone who runs this experiment should be able to understand and debug issues on their own. Remember that sidux still does not officially support aptitude in any way, so for the time being I suggest just being aware of that fact.

But since the only way sidux users can implement this option is to do the manual change to /etc/smxi.conf, that helps ensure that only people who can do this testing right will do it.

This is a nice time for basic testing too, since sid / testing are basically largely frozen until Lenny goes stable. However, the real Sid + aptitude tests will happen when junk starts piling into sid from experimental when Lenny goes stable.

But I have already now read reports from people running aptitude and Sid who not only have no problems, they like it, prefer it in fact. And I can already see why, more information is available to make decisions with. But that may be the reason it's frowned on I guess, you have to read and think a bit now and then, go through options.

By the way, once apt-type=... is set in /etc/smxi.conf, that enables the advanced miscelleous tweak option to set your preferred apt tpye, apt-get or aptitude. Same goes for setting du-upgrade= in /etc/smxi.conf (possible values: safe-upgrade (upgrade for etch) or dist-upgrade
Back to top

For better or for worse, I have used Aptitude in Debian almost from the start. I went Etch/Lenny/Sid pretty quickly as I learned, and it served me well through all my initial fumbling attempts at learning. I've had Sid on this box for well over a year, and have found no reason to complain about Aptitude to date.
Back to top

Forgive my lack of knowledge here, but how does Aptitude differ from apt-get?
Back to top

I've just tried out aptitude with sidux & smxi, and it works flawlessly. Thanks for the info regarding it. :)


It has better dependency handling, e.g. you get multiple choices for resolving dependency problems, and it also remembers which dependencies were installed along with a package, so it removes them when it's uninstalled (similar to apt-get autoremove). Packages can also be held with the aptitude hold command (rather than pinning). There's a few other things it can do, check out it's man page.
Back to top

As h2 said, I started some testing with aptitude a few days ago when xsane and xsane-common were out of sync, just to see how aptitude behaves, and the first choice was: to hold the newer xsane-common and keep xsane (apt-get always does it the other way round: it kicks the app - which starts to get quite annoying in Sid when you don't run smxi: you have to hold the stuff).

The kickback is the autoremove stuff, and sidux has the apt-get autoremove disabled (conveniently). Especially when someone is using synaptic heavily (which uses apt as backend but does not care about autoremove being disabled in the apt.conf).

This can be especially tricky when you install a kde metapackage, delete the few packages you don't need plus the metapackage. Do that with kde-graphics, kde-network, kde-multimedia ... and more or less all the kde goodies would be gone if one lets aptitude run.

My workaround was: putting all packages which were on "automatically installed" in synaptic to "manually installed" (not rocket science). But one just have to be aware of the fact otherwise one is lost with aptitude when mixing apt/synaptic and aptitude. The sidux apt-get configuration does not care about that, so no automatic removals when using apt-get with sidux.

A nice introduction into using apt and aptitude together is here: newbiedoc.berlios.de/wiki/Aptitude_-_using_together_with_Synaptic_and_Apt-get

I remember having read that mixing apt and aptitude might corrupt the database(s) they use (aptitude uses it's own), and nothing is working anymore. Though: I have not found anything like that on the net for the last two years, the issue might have been solved.

Anyway, this might be the solution if databases are corrupt:It is from here: www.debian.org/doc/manuals/reference/ch-package.en.html

As h2 stated: for sidux users this is experimental testing, and I will not advocate or support aptitude over at sidux.com, but aptitude seems to do a few tricks I really like, so I am personally insterested in (for Sid/sidux):

- behaviour when you mix apt/synaptic and aptitude
- behaviour when you need "apt-get -f install"

Maybe after the release of Lenny the boring times in Sid are over and I can dig more heavily into it because of packages being out of sync.

hubi
Back to top

Test 2: converted my oldest sidux install to aptitude. I should note that on both of these tests I'd done some major cruft cleanup in the past, so you'd probably see more packages removed.



This one I decided to do slightly differently, so after logging this data, I took the list of to be removed packages, and did: aptitude purge <package to be removed list> so I didn't have to then clean up their configs etc too.

This worked well, and made the conversion downright boring, I manually added apt-type=aptitude to /etc/smxi.conf, ran the dist-upgrade in smxi, nothing of interest happened, it just worked.

I am starting to suspect that some major improvements to aptitude re how it handles apt-get run systems have been done, these results are really good, as far as I can tell, nothing I needed got removed. (no, I don't use siduxcc). In fact, I'm starting to wonder if one thing aptitude does is look at whether the package has ever been run, although I'm not sure where it would get that information from, but that's almost what it seems like to me.

So I'm going to now run these tests on my main two sidux boxes for a while, that should give me a good idea of how well it really works. In the end, there's just no substitute for direct real world testing, on real systems that you use, so I'm not going to bother trying to emulate this, so far it all looks very good to me.

I still want to run one real Debian Testing machine to get a sense of how it works over time, and what packages might cause issues.

Small Issues I Found with Aptitude
1
Now that I'm starting to use aptitude full time on everything, I'll start finding issues. The first thing I noticed today was that, despite being very convient, and easy to remember, aptitude hold <package> and aptitude unhold <package> do not seem to change the core dpkg holds at all. I tested this to make sure, and that definitely seems to be the case.

Placing an aptitude hold did not set dpkg status to hi, and placing an unhold did not set dpkg status to ii. This doesn't seem ideal to me, since aptitude reads and knows the dpkg status fine, so you'd think it would write it to dpkg as well, to make it symetrical.

I would certainly prefer to just type aptitude hold... than remember the awkward: echo <package> hold | dpkg --set-selections

2
I initially tried using the default aptitude --with-recommends feature, but after it tried to do some really silly things, due to some really silly recommends, smxi now always uses --without-recommends in all aptitude install/du/upgrade operations.

For automated installs, the recommends just aren't a good idea from what I can see, and should in my opinion be turned off completely in /etc/apt/apt.conf

Because of the defaults, however, I'm going to keep using vanilla aptitude settings on my systems, plus what I hardcode into smxi, but in general, I recommend not installing recommends, just note them, and if you want them, install them manually.

In /etc/apt/apt.conf add this:


this is for apt-get I guess...

to turn this off.

hmm, more information


and a nice discussion on aptitude / apt-get that was pretty civil.
Back to top

About turning off autmatic installation of recommends, in sidux it is solved this way:

- config files are in the map /etc/apt/apt.conf.d/

The sidux adaptions are in /etc/apt/apt.conf.d/80sidux.

The apt-get conf syntax for recommends and suggests is:

This seems to affect aptitude as well, because default aptitude does not install recommends on this box with these settings in 80sidux.

hubi
Back to top

At some point in time will sidux turn to using aptitude instead of apt-get?
Back to top