Now smxi handles full abstraction for package manager. This will require some more testing, and only users with non sidux systems, new conversion, will see this option.

It's very important to understand how aptitude and apt-get work together, or fail to work together.

If you have been running your system using only apt-get, then DO NOT use aptitude, you need to prepare your system for that first.

If you have been using only aptitude, then you should use only aptitude.

Since Debian recommends aptitude now, and since I find myself more and more wrapping apt-get to be a bit more aptitude like, I think it's a good idea to start supporting the default debian package manager as well as apt-get.

For now, sgfxi and svmi do not support this, because it's harder for them to do it, although I may add tests there as well to use the default if I can figure out a reliable test for it.
Back to top

Does the Debian team recommend aptitude for unstable?
Back to top

I'm not sure, it takes some experience to really know what is best.

I think though if you ask irc.oftc.net which they recommend for sid and testing, they'd say aptitude.

By the way, because aptitude will tend to remove all of an apt-get installed system, I am not offering this option yet for antix by default.

You can set /etc/smxi.conf manually though if you want to test it:

apt-type=aptitude

and it will then use all aptitude in smxi. But you need to use one or the other, and if you used apt-get first, you need to really prep the system first to change.

You can read more on aptitude/apt-get in a thread I wrote while researching it recently.

I also, by the way, added an error trap that would remove all conversion files in conversion if user exits.

I just tested a new, fresh, business card install of kde+debian lenny, and it's fine, perfect, no issues at all, as long as aptitude is always used rather than apt-get.
Back to top

I found one small issue with aptitude, so far the only one: when I use aptitude install -d -y <kernel modules>, it proceeds to install them during the next upgrade, when it runs.

I'm not sure if the -y is the trigger flag, or what. Ideally I'd move these modules into the kernel download directory and out of apt cache, not sure if that will solve that issue or not.
Back to top