Page: 1, 2, 3  Next

aptitude + sidux - first test
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
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:
:: Code ::
apt-get install 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:

:: Code ::
aptitude upgrade 1>/home/username/aptitude-data-file

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:

:: Code ::
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Resolving dependencies...
The following packages have been kept back:
  gcc-3.4-base
The following NEW packages will be installed:
  libhd15{a}
The following packages will be REMOVED:
  djvulibre-desktop{u} empty-expect{u} g++-4.1{u} g++-4.2{u}
  gcc-3.3-base{u} gcj-4.2-base{u} gij-4.2{u} lib64gcc1{u} libc-ares1{u}
  libc-ares2{u} libc6-amd64{u} libcdk5{u} libconsole{u} libdc1394-13{u}
  libdmx1{u} libgcj8-1{u} libglide2{u} libhd14{u} libkmime2{u}
  libneon27-gnutls{u} libntfs-3g10{u} libntfs-3g12{u} libntfs-3g13{u}
  libntfs-3g14{u} libntfs-3g16{u} libntfs-3g21{u} libntfs-3g23{u}
  libntfs-3g24{u} libntfs-3g28{u} libntfs-3g9{u} libopenexr2ldbl{u}
  libparted1.8-9{u} libpoppler-glib1{u} libpoppler-glib2{u} libpoppler2{u}
  libpsiconv6{u} libqt4-assistant{u} libqt4-gui{u} libqt4-opengl{u}
  libsmi2ldbl{u} libsqlite0{u} libssh2-0{u} libstdc++6-4.1-dev{u}
  libstdc++6-4.2-dev{u} libsuitesparse{u} libsvg1{u} libx264-55{u}
  libx264-56{u} libx264-58{u} libx264-59{u} libxine1-gnome{u}
  type-handling{u} voikko-fi{u} xdg-utils{u}
The following packages will be upgraded:
  abiword abiword-common abiword-plugin-grammar abiword-plugin-mathview
  abiword-plugins acpi-support acpi-support-base alsa-base
  apache2-mpm-prefork apache2-utils apache2.2-common ark base-passwd
  busybox ceni console-data cpp-4.3 cups cups-bsd cups-client cups-common
...... and so on
wpasupplicant x11-common x11-xserver-utils xbase-clients xkb-data xorg
  xserver-xorg xserver-xorg-core xserver-xorg-input-synaptics
  xserver-xorg-video-ati xserver-xorg-video-radeon xutils
260 packages upgraded, 1 newly installed, 54 to remove and 1 not upgraded.
Need to get 383MB of archives. After unpacking 111MB will be freed.
Do you want to continue? [Y/n/?]

### then, when I ran it, I got this one question:
The following packages have unmet dependencies:
  libg2c0: Depends: gcc-3.4-base (= 3.4.6-6) but 3.4.6-8 is to be installed.
  The following actions will resolve these dependencies:
 
  Keep the following packages at their current version:
  gcc-3.4-base [3.4.6-6 (now)]
 
  Score is 120
 
  Accept this solution? [Y/n/q/?] y
 
 # and I accepted it, and the dist-upgrade continued.
 
 # after the du was done, I ran aptitude dist-upgrade
 # again, and it asked to remove lapack3 and libg2c0
 # and upgraded the dependency thing lib-gc-3.4 to new version
 # that's the only issue I saw, I'll research these packages
 # and see what they were. But for a system that was nearly
 # 2 years old, this is quite impressive, lots of packages
 # installed, almost flawless switch to aptitude. No need
 # to use keep-all or any other hack.


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

:: Code ::
apt-type=aptitude


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
UncleVom
Status: Interested
Joined: 12 Sep 2008
Posts: 21
Reply Quote
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
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
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
Ghstryder
Status: Interested
Joined: 08 Sep 2008
Posts: 24
Location: Michigan
Reply Quote
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
bowhuntr
Status: Interested
Joined: 08 Sep 2008
Posts: 15
Reply Quote
Forgive my lack of knowledge here, but how does Aptitude differ from apt-get?
Back to top
infectedsoundsystem
Status: New User - Welcome
Joined: 16 Sep 2008
Posts: 1
Reply Quote
I've just tried out aptitude with sidux & smxi, and it works flawlessly. Thanks for the info regarding it. :)

:: bowhuntr wrote ::
Forgive my lack of knowledge here, but how does Aptitude differ from apt-get?

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
hubi
Status: Interested
Joined: 08 Sep 2008
Posts: 16
Location: Vienna, AT
Reply Quote
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:
:: Code ::
6.3.4 Recover package selection data

If /var/lib/dpkg/status becomes corrupt for any reason, the Debian system loses package selection data and suffers severely. Look for the old /var/lib/dpkg/status file at /var/lib/dpkg/status-old or /var/backups/dpkg.status.*.

Keeping /var/backups/ in a separate partition may be a good idea since this directory contains lots of important system data.

If no old /var/lib/dpkg/status file is available, you can still recover information from directories in /usr/share/doc/.

     # ls /usr/share/doc | \
       grep -v [A-Z] | \
       grep -v '^texmf$' | \
       grep -v '^debian$' | \
       awk '{print $1 " install"}' | \
       dpkg --set-selections
     # dselect --expert # reinstall system, de-select as needed
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
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
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.

:: Code ::
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
The following NEW packages will be installed:
  libprojectm-data{a} libprojectm2{a}
The following packages will be REMOVED:
  amsn-data{u} djvulibre-desktop{u} empty-expect{u} g++-4.2{u} ladcca2{u}
  libaudacious5{u} libbinio1c2{u} libc-ares2{u} libc6-amd64{u} libcdk5{u}
  libdmx1{u} libebml0{u} libfluidsynth1{u} libglide2{u} libisc41{u}
  libltdl3-dev{u} libmatroska0{u} libparted1.8-9{u} libprojectm1{a}
  libprojectm1-data{a} libpsiconv6{u} libqt4-gui{u} libqt4-opengl{u}
  libresid-builder0c2a{u} libsidplay2{u} libsnack2{u} libsqlite0{u}
  libstdc++6-4.2-dev{u} libstring-shellquote-perl{u} libsvg1{u}
  libxalan110{u} libxerces-c28{u} siduxcc{u} siduxcc-common{u} sshstart{u}
  voikko-fi{u}
The following packages will be upgraded:
  cdparanoia console-data cpp debian-reference-common debian-reference-en
  distro-defaults eject fastjar firestarter g++ gcc gcj-4.3-base
  gfxboot-theme-sidux gfxboot-theme-sidux-2007-04-eros gij gij-4.3
  grub-gfxboot htdig initramfs-tools libcairomm-1.0-1 libcdparanoia0
  libdb4.2 libdb4.3 libdb4.4 libdb4.5 libdb4.6 libdb4.6++ libgcj-bc
  libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-jar libical0
  libmysqlclient15off libparted1.8-10 libvisual-projectm libx11-6
  libx11-data libx11-dev login mysql-client mysql-client-5.0 mysql-common
  mysql-server-5.0 nfs-common openoffice.org-base openoffice.org-base-core
  openoffice.org-calc openoffice.org-common openoffice.org-core
  openoffice.org-draw openoffice.org-filter-binfilter
  openoffice.org-filter-mobiledev openoffice.org-help-en-us
  openoffice.org-impress openoffice.org-java-common openoffice.org-kde
  openoffice.org-math openoffice.org-style-andromeda
  openoffice.org-style-crystal openoffice.org-writer parted passwd
  python-uno rcs ttf-unifont unifont virtualbox-ose
  virtualbox-ose-guest-modules-2.6.26-5.slh.4-sidux-686
  virtualbox-ose-modules-2.6.26-5.slh.4-sidux-686 virtualbox-ose-source
  x11-common xbase-clients xfonts-unifont xlibmesa-gl xnest xorg
  xpdf-common xpdf-utils xprint-common xserver-xorg xserver-xorg-core
  xserver-xorg-dev xserver-xorg-video-vesa xterm xutils xvfb
87 packages upgraded, 2 newly installed, 36 to remove and 0 not upgraded.
Need to get 204MB of archives. After unpacking 67.8MB will be freed.
Do you want to continue? [Y/n/?]


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:
:: Code ::
Aptitude::Recommends-Important "false";


this is for apt-get I guess...
:: Code ::
APT::Install-Recommends=no

to turn this off.

hmm, more information
:: Quote ::
To not treat recommendations as dependencies in aptitude, just put
Aptitude::Recommends-Important "false"; in your ~/.aptitude/config or
/etc/apt/apt.conf or give -R option (aka --without-recommends) in the
aptitude command line. source


and a nice discussion on aptitude / apt-get that was pretty civil.
Back to top
hubi
Status: Interested
Joined: 08 Sep 2008
Posts: 16
Location: Vienna, AT
Reply Quote
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:
:: Code ::
APT::Install-Recommends "0";
APT::Install-Suggests "0";


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
bowhuntr
Status: Interested
Joined: 08 Sep 2008
Posts: 15
Reply Quote
At some point in time will sidux turn to using aptitude instead of apt-get?
Back to top
Display posts from previous:   
Page: 1, 2, 3  Next
All times are GMT - 8 Hours