intertwingly

1.15 is the one that always gets me...

(Really, expecting downgrades to be supported is insane, but the crap usability of the tools is inexcusable.)

Hilarious, but also a little unfair. It mixes separate issues — some IMHO rather minor inconsitencies regarding naming, and the fact that one practically has/had to run the “unstable” and “testing” distributions due to the long release cycles of Debian. As luis above said, expecting downgrades to work is a little... optimistic, and I don’t recall even trying something like that when I used SuSE — SuSE would break on its own, without any downgrades.

Theses days I’ve jumped on the Ubuntu bandwagon and enjoy the fast releases and the excellent Debian package management.

But the ubuntu package management isn’t excellent; at the command line level it is the same maddeningly inexplicable and inconsistent debian crud.

Granted, I’m partisan; I think the consistency, flexibility, and power we had with red carpet c. 2002 were better than anything anyone offers right now.

Interesting, thanks for sharing. As a sort-of counterpoint, I still get caught out at work, dealing with Redhat and CentOS-base machines, when I can’t do something I’ve learned to take for granted in Debian (the recommended upgrade path is reinstall!?!?!)

I have “moved” one machine across releases (Mandrake/Mandriva) for 8 years using rpm+urpmi, and also have experience on continuous “evolution” using gentoo like 5 years. I did also minor debian admin tasks, but never had full responsability for a machine.

As a newbie using apt/dselect/dpkg over Ubuntu, I have already been biten by the most annoying problem in the packaging system (lest the inconsistency in naming, procedures, commands and options be considered): the lack of a serious “verify”  option.

At one step in my system, the eeeubuntu base-files package had at least /var/tmp with the wrong mode. I can’t find a way to verify the package, like rpm --verify or equery check would do. I guess there isn’t. What is worse, it is not trivial to find how to “force” a reinstall, and even then I’m not sure the files would get the proper modes.

This misfeature breaks the principle of reproducible installs, the fact that reinstalling all packages on a broken system a finite number of times should eventually “heal” the system to a working condition. I still don’t want to blame inability to verify installed packages on the packaging system, as I’m not an expert in the mess of commands and options, but I really can’t find how to verify a package as installed or reinstall it so that directories will get proper ownership and modes.

Any clue?

I’ve posted an “updated” (and slightly tongue-in-cheek) version of this FAQ on my blog.

Santiago: debsums, although that doesn’t do file modes. dpkg --purge and reinstall should do what you want, although removing base-files is probably a bad idea. Debian package scripts are supposed to be idempotent, but file modes come straight from the tar file so eeebuntu may just have a faulty package. dpkg-statoverride does store file owner/mode information, but is only used for nonstandard permissions.

A better map of the apt state files covers some of 1.15, although ignores the fact that dselect is deprecated.

I’ve occasionally had to use an RPM based system, and never worked what the options were to do what I wanted. My desktop is running the same install of Debian from 2000 that I’ve migrated over three machines, and I help admin several others that were last reinstalled in 2003 and have also moved hardware over the years. One important tip to do this is to read the release notes for the upgrade procedure, as it’s sometimes not as simple as aptitude dist-upgrade.

James, I know that eeeubuntu had a faulty package. Errors happen. What concerns me is that I have installed at least two correct upgrades on top of it, including a big 8.04 -> 8.10 upgrade, and neither were able to correct the problem or even to warn me that the package was not conformant. The permissions and modes of the tar is right in the currently installed package, just not in the filesystem until I corrected it by hand.

It scares me because it means that any mode error in any package installed in the past will stay there forever and I have no way, except collateral damage, to learn about it. This definitely won’t happen either in rpm packaging or in portage systems.

Looking at the dpkg source, this bug can only happen with directories. Files are explicitly extracted as 000 then set to the mode from the tar file. Would you like to file the bug on dpkg or shall I?

I didn’t even know it was a bug and considered it a feature, given that the state information does not include file/directory modes, but just name and md5 sums (for files). So I guess you should, I don’t even speak the required jargon  :)

Debian bug 515211. Vaguely related is the fact dpkg clears suid bits on upgrade preventing a hardlink attack on suid binaries.

Some of the first questions can be answered with aptitude. Not sure why people still use apt-get/apt-cache. It should support the functionality of gdebi too, and install/resolve dependencies for .deb files.

I would love to read Mark Pilgram’s take on this. Maybe when he comes out of the ball pit.