APT - With Your Favorite Distribution

One of the most-heard complains from people who use distributions like Red Hat, Mandrake or SuSE is the "dependency hell" problem. You want to install an RPM and bang -- you have a dependency problem. There have been a few attempts to overcome dependency problems: SuSE with their YOU (Your Online Update), Mandrake with URPMI, and Redhat with their UP2date program. There is also a solution from Aduva called Aduvizor, but it's not supporting the latest distributions yet. Read on to learn about another interesting solution ... One of the solutions is Ximian Red Carpet (which is available to most of the distributions, freely or by subscription for increased download speed), however Red Carpet has one big problem -- if the package is not on Ximian Red-Carpet servers (like, umm, KDE packages), you're (again) on your own.

Then there is another solution from Connectiva in Brazil, which has made something called APT4RPM -- basically an APT wrapper around RPM database on your machines, so you can use all of Debian's APT features (sans DSELECT feature) to upgrade your packages, or your entire distribution. (So now you can use your favorite distribution AND APT to update it.)

Two open source developers have improved Connectiva's solution to work with ANY RPM-4 based solution, and the [not finished yet but seems pretty stable solution] is at APT4RPM project pages in sourceforge. I have decided to give a test on my Redhat 7.2 machine. I installed the binaries, edited the /etc/apt/sources.list (just remove the # from your distribution's mirror), typed "apt-get dist-update," crossed my fingers -- and lo and behold, 48 new packages were installed, 7 were upgraded, and I only had to press "enter" to start the ball rolling!

So, for those of you who want to test it -- the URL is above (and if you could help with creating mirrors for your favorite distribution - that would be very helpful, thank you), you might want to try it. Just don't forget to read the FAQ before doing anything, and report bugs to the authors. Note: although the binaries are for Red Hat, the SRPMS are right there so you can just recompile it on your favorite distribution. Enjoy.

Comments

run slackware

[Eil]

This was one of the reasons I moved to slackware. Virtually no package management. You want software? Get the darn tarball and have at it. Configure will tell you if you don't have the right dependencies. It has worked wonderfully for me. Yes, I know of the disadvantages of slackware's lack of package management. They are smaller than the advantages, imho.

On that note, I think since Slackware pretty much starts at nothing in the PM arena, it would be a great candidate for some kind of apt-get-type system. But that would, after all, pretty much collide with slackware's motto of being kept exceedingly simple. (Almost to a fault, some might say.)

Re:run slackware

[ThatComputerGuy]

While that is one of the more popular stances of Slackware users (and we're damn proud of it!), credit should be given where it's due, so it should be mentioned that slackware does actually have a Package Management System (hah! PMS! Get it?).

Ever check the contents of files in /var/log/packages on a slackware system? Each file is for a different package, and simply lists all the files a package requires, total size, description, priority, etc.

Go to linuxmafia.org, download the latest package for say, kde-2.2.1 since you see no reason to compile it yourself, and use the installpkg command, ie: "installpkg kdelibs-2.2.1.tgz".

Then go check the contents of /var/logl/packages/kdelibs-2.2.1, and voila, all the files kdelibs installed/needs, the total filesize, etc

Want to get rid of a package you don't need anymore? "removepkg kdelibs-2.2.1" will do the trick. If there's a file in kdelibs-2.2.1 that any other package in /var/log/packages needs, it won't be removed.

Want some sort of crappy gui to use for messing with packages? "pkgtool" allows you to install packages, remove packages that are already installed, and view package contents, while being slightly more friendly than having to grep each package file or opening all of them in your favorite text editor (vi, of course).

Simple package management at its best.

What apt is about...

[sydneyfong]

the thing which makes apt really cool is not because it's using debs instead of rpm's.

It's cool because

1. For debian testing/unstable you can get daily updates to your system. For stable you can get daily security updates.
2. You know updating your system will be a simple, painless and easy process. You know it will automagically work after two shell commands.
3. It is much more configurable than most RPM interfaces.
4. There is usually one "kind" of debs, which come officially from Debian.org, instead of a million different RPMS for Redhat/Mandrake/SuSE etc which conflict with each other
5. You have almost everything you need. If you use "unstable", you will always be on the "bleeding edge" with not too many problems, rather than waiting for distros to release their latest CD, and then sometimes trash the whole system because of a failed upgrade.
6. And of course, without the dependency hell! ;-)

As you see, dependency hell isn't the whole reason why people prefer apt above RPM based systems. Before they solve these problems, debian/apt will still be my first choice.

/usr/local

[sporty]

My major gripe about the way linux distribs work is that they like to install stuff right into /usr/bin and /usr/lib.

I'd enjoy it if the base system stayed in /usr/bin, /usr/lib etc etc and whenver i wanted to, just rm -rf /usr/local (or /usr/X11R6 for X stuff) and be done with it. Plus removing the /var/db/pkg (or where-ever the package db files are stored)

Re:/usr/local

[Arandir]

You way of doing things is the RIGHT way of doing things. A few Linux distros do it the right way, but they are few, seldom seen, and never in the top three list.

/usr/local and /opt are there for a reason. The only reason there's a /usr/X11R6 is because of stupid tradition, but there's no reason it couldn't be a symlink to /usr/local/X11R6.

/usr is for the base system. /usr/local is for anything that you install after the initial install, even for stuff that ships with the OS. /opt is optional, but useful for network installations so that what the user installs is under /usr/local and what IT/administration installs is under /opt.

Re:The problem is with the RPM format...

[Ed Avis]

The RPM format at best only provides the name and major version of any dynamic libraries a package requires.

Have you ever actually used RPM? It allows you to specify prerequisites with their versions in more or less the same way as dpkg. Certainly a lot more than just the version of shared libraries.

It's true that a lot of RPM builders do not bother to include this information. But that's not the fault of the format itself. A lot of the claimed advantages of .deb over .rpm are really just because the Debian people are more conscientous about packaging and anal (in a good way) about getting the dependencies correct. Ditching RPM is not the answer, better packaging quality is.

Re:My take on it.

[Whelkman]

"Most Debian Developers take care of a *single* package."
What? How do you know?

This one's pretty easy. The maintainers' names are plastered all over the place and there are easy referencing methods. He's mostly right, though I think the norm might be something like two or three packages.

"the Debian packagers *care*"
Really? More than people who make rpms? How much more do they care?

This is subjective, but it's very easy to get in tough directly with the maintainers, who usually listen to your problems.

Re:[OT] Make System

[juhtolv]

One possibility is to use

GNU stow
.

Re:My take on it.

[dvdeug]

"the Debian packagers *care*" Really? More than people who make rpms? How much more do they care?

I have three packages in Debian that I am personally responsible for. I'm very familiar with each of those packages, in a way that no one that packages a hundred packages can be. I'm also very responsible for each of those messages - Debian has a tracking system for bonehead mistakes (and other things) that I like to keep clean. Almost no RPM developers have that combination, and it functions the same way for many of my fellow developers.

Re:[OT] Make System

[SW6]

I wanted to know if you install something using

./configure
make
make install
Is there anyway to uninstall it?

"make uninstall" will work in a lot of cases. With applications that use ./configure, it's usually pretty easy to turn it into a Debian package that you can install from by using the debmake, devscripts and sudo packages.

Go into the directory where ./configure is, and type "deb-make". Normally you want a "S"ingle Binary. This has now created a Debian build tree. Try to convert it into a package by running "debuild -rsudo". Hopefully this will spit out a .deb file in the parent directory. You can now install this by running "sudo debi". Dead easy.

To recap:

deb-make
s
debuild -rsudo
sudo debi

The package can be removed like any other package, e.g. via dselect.

Slackware's priorities...

[Marasmus]

Another thing which seems to be rarely mentioned is that Slackware tries to be both Linux- and BSD- compatible, to as reasonable a degree as possible. In fact, it was one of Slackware's founding principles ("create the most unix-like linux possible"). Another strong rationale for us Slackware fans is that it's trivial at best to debate differences between most BSDs and Slackware. Hell, even Slackware's install script is a look-alike of FreeBSD's. :)

Further down in this thread, someone mentioned the /usr/man versus /usr/share/man thing, etc etc... /usr/man is generally BSD-like, while /usr/share/man is Linux-like (linux filesystem standards dictate this). Also of important note is that in Slackware, /usr/share/man is a symlink to /usr/man. This leaves Slackware with a BSD feel while maintaining full Linux compatibility.

Everyone makes a big deal about compiling from source in Slackware, or "not having a package management system", but completely ovelook the reasons why slackware doesn't appear to focus on package management.

• Slackware is as unix-like as possible. POSIX (correct me if i'm wrong) does not dictate any package management standards of any sort.
• Slackware's (very under-used) .tgz package manager is simple and works with VERY few problems. It's similar, though not straight-up compatible, with the BSD packages and ports... The package manager is very slackful itself, and allows you to compile lots of stuff yourself without unnecessarily bitching about dependencies. Sure, it can lead to non-uber-developers missing a dependent library when installing something big, but they can go back and add that library either by source or by package, and all is good.
• Many RedHat-built packages (provided they're not built on GCC 2.96) work very well with Slackware, especially when converted to .tgz using rpm2tgz or any of its accompanying tools. These tools allow you to have the best of both worlds (fully packaged software and a super-lightweight, nearly transparent package manager).

Slackware's developers follow the line of thought that package management is not and never will be an end-all solution to software installation on a *nix operating system. Instead of trying to force package management down the throats of their users, they prefer to take a split approach, giving some fairly good package management capabilities (also THE easiest to learn out of any linux package manager - it's SO simple) without discouraging source-compilation of software.

forgive me if i've repeated myself a thousand times. i'm just ranting. :)

Mandrake's URPMI works quite well

[opkool]

Hi,

I use both Mandrake and Red Hat. And IMHO, urpmi is better than up2date. I've been using urpmi (or its GUI interface, MandrakeUpdate) for a while.

And URPMI just plain works.

Every day, I fire it up to check if there's something to be updated on my system. If there is, I upgrade no problem. If there are dependencies, you can opt what to do. And it has the same interface as the SoftwareManager. So it's the same thing installing, uninstalling or upgrading.

This is called consistence.

I've read that some poster tried to update the Kernel with this tool from the GUI. I can only say "you moron!". When there's some Kernel to be upgraded, some library to be upgraded, I take my time to read what is this alla bout. So, reading a little can save your butt. What is wrong with that ?

Also, when updating KDE make sure that you are not running KDE. Idem with Gnome.

Anyway, I would recommend to home users wanting to avoid rpm-hell to try Mandrake + URPMI / MandrakeUpdate.

Hopefuly, Red Hat will take URPMI and implement it on their distribution.

All the best,
opkool
(sorry for the extension).

Re:rpm and dpkg package verification....

[psamuels]

I have read that the dpkg based " debsums -a " is inferior to " rpm -Va ", but noone could quite explain why.

I believe that RPM packages always have md5 checksums on all the files, whereas .deb packages, by default, do not.

That's probably what you heard.