No. sidux supports apt-get. This here is testing for smxi. My involvement here is not official (regarding being member of the sidux manual team), purely for fun and out of interest.

hubi
Back to top

Ok, let me rephrase this, at some point, will smxi give the option to use aptitude instead of apt-get?
Back to top

Maybe I am meandering a bit off, but this might be interesting for me on my laptop at work.

This laptop I run quite conservatively, over long periods I only update packages when they have security upgrades (I cannot afford to rush into sudden Sid showstoppers like printing not working - no other system is installed, just sidux).

I use debsecan to trigger the Debian database for security updates in Sid and use this command:

"apt-get install" completely disregards any dpkg status hi, and if a security upgrade would break the usability of a package I could not use this way of maintainance at all.

So I tried this command when the last security update in Sid came in (mysql a few days ago):

The command does what it should do, and aptitude might/would give me the possibility not only to avoid problems with out of sync dependencies but also to hold a package, which would mean that this way of maintaining that box might/would not break when Sid breaks. That is very interesting indeed.

hubi
Back to top

bowhuntr, since converting requires a manual process of confirming packages that aptitude will remove, as indicated in this thread, an automatic process for sidux users will never occur, until such a time sidux looks at aptitude again, which I suspect they should start thinking of doing on test vm installs now, again. But that's up to them completely.

So to run aptitude requires that you do the explicit manual conversion, as indicated in this thread, then setting /etc/smxi.conf to use: apt-type=aptitude

This will then changeover all smxi functions to use aptitude where appropriate. It will also activate an advanced misc tweak option to set apt type, which is hidden for sidux users unless smxi.conf has been manually altered.

smxi, sgfxi, and svmi all use either apt-get or aptitude depending on user selections and preferences, sidux users simply default to apt-get method. Most of the smxi changes over the last few months were not visible to sidux users, since they involved increasing the flexibility and range of user choice outside the range supported by sidux, to encompass debian proper as well.

This won't change, the sidux official policy on apt-get is clear, and they shouldn't be asked or expected to support issues from people who might run into problems using aptitude, a system they explicitly do not support. But which so far I'm liking a lot.

The more empirical evidence collected here by people willing to do such tests though, the less you have to worry, but the real tests come when the big floods of new packages come in, kde4, and so on, after Lenny goes stable.

If aptitude continues to work through those bumps, I will completely recommend it, but sidux users will never see it by default unless sidux changes their official policy.
Back to top

Thanks, h2, I was just wondering about all of this.
Back to top

Regarding the huge list of removals when switching from apt-get to aptitude on a sidux installation. Could it be solved with this command as initial command?

This sets all installed packages to "manually installed" and should cause that the second command sequence does not show any removals:

hubi
Back to top

I like the lists of packages to be removed so far. I haven't had more than a few that I wanted to reinstall, its judgement was quite good in my opinion.

But nothing is as good as building the system using aptitude to begin with, then the removals etc will always work very well.

But I'll run my two sidux systems for a while using aptitude.

As you saw with my two lists, when I researched the packages, almost all were obsolete or not needed.

And, I might note, xmms, and other packages like that, did not get removed. So I think aptitude is being quite clever here. I was most impressed on my first etch testing system, where I'd accidentally installed the full debian kde metapackage, and when I ran aptitude on that, it basically removed almost all the packages I didn't need, and removed only a small handful of packages I needed, which I then reinstalled. On that one too, no packages I used or really needed where removed, except I think 2 kde things, but even those I'd actually never used.

That was the list I'd posted about on the sidux forums in some old aptitude/apt-get thread, and now I'm slightly embarrassed about that, the list was excellent, and almost every single package on it was not needed by the system, I have never missed one. And that's old aptitude, etch era.
Back to top

I still do not get the point: what triggers the removals at all. But it is quite disturbing (I also posted a huge list once at sidux.com), maybe there were fewer essential removals that I thought.

But your comment gave me the idea to make another testrun. As I said I like synaptic, so I installed kdeaccessabilty as metapackage which pulls six packages with synaptic.

After that I removed the metapackage with atpitude (goal: I want to remove all unwanted dependencies). And aptitude did the trick:

So even mixing after the initial disturbance is cleared does not seem to affect aptitude negatively.

hubi
Back to top

One key point some might have missed here: on both systems, I had done a manual cleanup some time ago, removing a lot of packages. So the intitial aptitude remove lists would have actually been much longer, but again, longer because there was so absurdly much cruft in the old systems.

I was initially going to script that logic into smxi, to create the correct cruft list, which is complicated and takes a long long time to generate because it actually reads all current package status lists per package, and requires manual editing etc, but now I see that what I was trying to do aptitude already does natively.

And that cruft buildup is what convinces me that aptitude is the real tool for a serious long term debian install. Not these reinstall every release things, I mean a real, running, true debian install that you never reinstall.

By the way, one reason I decided to look into aptitude was I started to realize that more and more, I was getting pulled to implementing, or thinking of implementing features in smxi caused by shortcomings in apt-get.

Fortunately for me, I stopped in time, and realized that what I was about to do was try to reimplement aptitude, which is being done by people who I assume find more or less the problems with apt-get that I do, and have designed aptitude to resolve those problems.

By the way, in both new apt-get and aptitude, it's: aptitude purge OR apt-get purge
no remove is needed.
Back to top

I just found another nice aptitude thing: when I was testing a purge operation with -s flag, simulate option that is, I forgot to su to root.

aptitude purge -s <package name>
worked fine as user but apt-get purge -s <package name> demanded root.

This is a small thing I admit, but it's one of many small things I'm finding that are well thought out and of utility with aptitude.
Back to top