Debian & apt-get

Ice9 · Post by **Ice9** » Wed Dec 08, 2004 3:12 am

Is apt-get for Debian more powerful than apt4rpm?
A few weeks ago I erased FC from my hard drive and began tinkering with a lot of different distros.
Among the ones I tried out are:
Yoper, Mepis, SuSE, Mandrake, Xandros, Alt Linux Junior, ARK and I've had Libranet 2.8.1 on another partition for quite some time.

Every install went pretty smoothly, appart from little quirks that I could fix pretty easily.
The one thing that the Debian-based distros had was that I broke them all, and all at the same stage ...

Code: Select all

install - everything OK
apt-get update
apt-get upgrade

After that they all became unusable to various degrees, dropping me at a failsafe prompt with no KDE/Gnome, unable to start X, or looping between the nvidia splash screen and a black screen for more than 10 minutes ...

In the past years I've used RH and FC with apt4rpm and my system NEVER became unusable!
As for the rpm-based distros I tried out I didn't like them too much but they didn't break, Xandros didn't break either but then again I wasn't able to get apt working

I plan to dig a little deeper since I really like the Debian philosophy and I really would like to be able to use a Debian-based distro as OS but if I keep breaking my system at nearly every apt-get upgrade I do .....

I'd be happy to hear your thought about this.
Is apt-get more powerful than apt4rpm?

Void Main · Post by **Void Main** » Wed Dec 08, 2004 10:09 am

Well, apt4rpm is actually the same code as apt for Debian. Neither is "more powerful" than the other. Apt is just a front-end to the underlying package management system. On Red Hat based distros apt would execute "rpm" commands and on Debian distributions it would execute "dpkg" commands. If your system becomes "broken" when you upgrade via apt it probably isn't apt's fault, but the fault of whatever package in whatever repository you are upgrading from. If you have broken packages in broken repositories you are going to end up with a broken system. I personally have never had a problem in either Debian *or* Red Hat that caused a problem serious enough where I couldn't recover from. I have had broken packages though from some 3rd party repositories but if you understand rpm (or dpkg) and dependencies then it's not a problem fixing. I personally have had outstanding luck with the Dag Weier related repositories for the Red Hat distros. You do have to take care in not mixing certain repositories though.

Regarding nVidia problems after an upgrade via apt (or just upgrading to the latest software not using apt, but with the base package tools would have the same result) that is because nVidia is a 3rd party driver that is not part of a repository (at least on the Red Hat repos). If you ugprade your kernel, or your GL libraries you must understand that you are going to have to reinstall your nVidia driver. If you use the free nVidia drivers (not the drivers actually from nVidia) then you shouldn't have a problem, but you will not have hardware acceleration. I try to run my systems with as close to stock software + Dag as possible. Most of my machines are 100% stock + repo with no 3rd party installed software. My main desktop has two 3rd party packages that I have to watch during upgrades and that is the nVidia driver and the VMware drivers. But that is only an issue if I upgrade the kernel itself (which doesn't get upgraded on an "apt-get dist-upgrade").

Ice9 · Post by **Ice9** » Wed Dec 08, 2004 1:41 pm

You do have to take care in not mixing certain repositories though.

Nothing but the stock repositories that came wth the different distros ...

If you ugprade your kernel, or your GL libraries you must understand that you are going to have to reinstall your nVidia driver.

I know that, but didn't do a kernel upgrade, gl libraries possibly but since I was wirking with the driver provided by the distro itself I wouldn't imagine this to be the source of my problems.

I try to run my systems with as close to stock software + Dag as possible. Most of my machines are 100% stock + repo with no 3rd party installed software

That's what I also try to do, and in fact all I wanted to do is perform an update right after installation just to be up-to-date with the security fixes and all ...

What led me to ask if there were differences between both systems is that with apt-get on Debian I always had to answer to script configuration questions where I had the choice to either keep my settings or install the script provided by the package maintainer, I never had to do that with apt4rpm ...

Void Main · Post by **Void Main** » Wed Dec 08, 2004 2:32 pm

Ice9 wrote:
You do have to take care in not mixing certain repositories though.
Nothing but the stock repositories that came wth the different distros ...

Actually I don't use the Fedora repos. I use Dag exclusively, and you can't mix them.

If you ugprade your kernel, or your GL libraries you must understand that you are going to have to reinstall your nVidia driver.
I know that, but didn't do a kernel upgrade, gl libraries possibly but since I was wirking with the driver provided by the distro itself I wouldn't imagine this to be the source of my problems.

I've never used a distro supplied nVidia package so I guess I can't really comment on that.

I try to run my systems with as close to stock software + Dag as possible. Most of my machines are 100% stock + repo with no 3rd party installed software
That's what I also try to do, and in fact all I wanted to do is perform an update right after installation just to be up-to-date with the security fixes and all ...

It would be nice to know the specifics of the problem that you had, I might have been able to help.

What led me to ask if there were differences between both systems is that with apt-get on Debian I always had to answer to script configuration questions where I had the choice to either keep my settings or install the script provided by the package maintainer, I never had to do that with apt4rpm ...

Yes, when you install a package in Debian you are usually presented configuration options but that is not a function of apt, but a function of the package itself. I'm not sure but I think you could provide similar type of configuration scripts with any RPMs and call them in the "%post" section of the spec file. In the RPM based distros any configuration is usually done automatically or to some default. Not saying any one way is better or worse, I like both ways, I use both distros. It is nice that Debian packages are usually set up to do this customization and you can pass a parameter to just take the defaults if you wish. I would say this is an advantage of Debian. However, I like the defaults in nearly all Fedora packages so... :)

Ice9 · Post by **Ice9** » Wed Dec 08, 2004 4:03 pm

Void Main wrote:

It is nice that Debian packages are usually set up to do this customization and you can pass a parameter to just take the defaults if you wish. I would say this is an advantage of Debian. However, I like the defaults in nearly all Fedora packages so...

Hehe

The difficult part is that you see a message like

Code: Select all

script x has been modified since installation, either by you or by a software update.
There is a new package provided by the package maintainer, what would you like to do?

Since I don't know what has been modified I can't tell if my previous configuration still works.
So first I tried to keep all my previous configs, since that is the default, no more KDE/X/etc...
Then I tried to replace everything with the newly provided packages, same result ...

But I'm back in X now, Mepis provides you with a little utility to repair broken stuff and I was able to reinstall X by booting the live CD and clicking a few buttons.

Void Main · Post by **Void Main** » Wed Dec 08, 2004 4:54 pm

That's cool. I've been meaning to try Mepis. What do you think about it outside of the update problem?

Ice9 · Post by **Ice9** » Wed Dec 08, 2004 5:04 pm

Pretty cool actually, everything works right out of the box.
The only drawback as far as I'm concerned is the fact that some of the software listed in synaptic is uninstallable because of unmet dependencies

mplayer for instance is installed without GUI enabled.
No biggie I thought, just uninstall mplayer-nogui and install mplayer, .... nope mplayer won't install because of unmet dependencies, same for the mozilla-mplayer plugin.

Apart from that it's pretty much what my FC2 install was after a couple of hours of heavy modding

Edit

mplayer for instance is installed without GUI enabled.
No biggie I thought, just uninstall mplayer-nogui and install mplayer, .... nope mplayer won't install because of unmet dependencies, same for the mozilla-mplayer plugin.

Just fixed that with:

Code: Select all

apt-get -t unstable install mplayer-586

It installed all the missing libraries and all

Void Main · Post by **Void Main** » Wed Dec 08, 2004 6:09 pm

Well, installing dependent packages is pretty much the entire point of apt. :) The base package managers do not do that by themselves (rpm/dpkg).

Ice9 · Post by **Ice9** » Thu Dec 09, 2004 2:00 am

Void Main wrote:

Well, installing dependent packages is pretty much the entire point of apt.

But that's my point, I did try to install it using apt!
I used dpkg a little at first but I like apt a lot better, only problem I found so far using apt on Debian is the repositories, I can't seem to find the same structure within repositories as I did with apt4rpm.
Apparently some people create repositories with packages linked to other packages/libraries in stable/testing/unstable repositories and I'm somewhat confused when I try to install a package from a certain repository only to find that I have to look for a certain library in another repository I don't have in my sources.list yet.

Void Main · Post by **Void Main** » Thu Dec 09, 2004 9:16 am

Ice9 wrote:Void Main wrote:
Well, installing dependent packages is pretty much the entire point of apt. :)
But that's my point, I did try to install it using apt!
I used dpkg a little at first but I like apt a lot better, only problem I found so far using apt on Debian is the repositories, I can't seem to find the same structure within repositories as I did with apt4rpm.
Apparently some people create repositories with packages linked to other packages/libraries in stable/testing/unstable repositories and I'm somewhat confused when I try to install a package from a certain repository only to find that I have to look for a certain library in another repository I don't have in my sources.list yet.

A lot of people are confused as to the differences of apt and dpkg. They are completely different tools. dpkg is the actual package management tool use on Debian based distros. apt is just a front-end for dpkg. You can not use apt "instead of" dpkg but when you use apt you are using it "in addition to" dpkg. Think of it as a "dpkg helper". I know you probably know this but for anyone following along your first sentence sounds like you can use one or the other.

Now, regarding your repository I believe I see why you might be having problems. Debians release naming convention is a little confusing. I personaly do not like to mix stable/testing/unstable repos for the similar reasons I do not like to mix FC3/FC2/FC1 repos toget in the Red Hat world. Or maybe closer would be mixing Dag and Fedora repos. This might give you a little better understanding:

http://www.debian.org/releases/

It's still a little different though as "theoretically" you shouldn't run into dependency problems. My experience is different the closer you get to the "unstable" release. But all of this assumes you are actually using "Debian" and not a "Debian based" distro. Who knows what sort of custom packages a 3rd party Debian based distro might create along with associated dependency issues. I have had great luck with using the real Debian.

Ice9 · Post by **Ice9** » Thu Dec 09, 2004 9:56 am

Void Main wrote:

But all of this assumes you are actually using "Debian" and not a "Debian based" distro. Who knows what sort of custom packages a 3rd party Debian based distro might create along with associated dependency issues. I have had great luck with using the real Debian.

I think this is where the real problem lies because at first I didn't add any repository and there was a lot of stuff that wouldn't install because of unmet dependencies.
This shouldn't happen when you use the stock apt config from a fresh installed distro.

I realize that you can't mix the different releases without risking to break your system completely, in fact I broke my libranet install by trying to upgrade KDE from unstable

I'll try to do a dist-upgrade from unstable tonight and see what the result is, if I end up breaking Mepis I might give FC3 a try

Void Main · Post by **Void Main** » Thu Dec 09, 2004 10:00 am

Ice9 wrote: This shouldn't happen when you use the stock apt config from a fresh installed distro.

But which distro are you referring to? The current Debian stable? I have not had problems with that one so I would like to know more specifically where the problems are (which packages on Debian stable). I would like to see your sources.list file and the exact commands you used with the exact errors that were produced.

Ice9 · Post by **Ice9** » Thu Dec 09, 2004 10:12 am

No, no, not Debian but Debian-based.
I'm talking about Libranet 2.8 and 2.8.1, various versions of Mepis and Xandros.

Void Main · Post by **Void Main** » Thu Dec 09, 2004 11:42 am

Ice9 wrote:No, no, not Debian but Debian-based.
I'm talking about Libranet 2.8 and 2.8.1, various versions of Mepis and Xandros.

I can't help you with those because I don't have any experience with them. Mepis is the only one that I might possibly look at but we're still talking about Debian "based" distros and not "Debian". I would have to assume that they are running their own customized packages or what would be the point of even existing? Because of that I would "expect" to have problems by pointing at Debian repositories. If the distro was any good they would have their own repositories of packages tested against their own distro and I agree, those should work. If they don't then that's the problem of the Distro, not Debian, and not apt.

Now, Debian itself has a vast amount of software out there, more than any other distro so I know it would surely be tempting to just point at those repos and install away but I don't see how one could complain tha Debian or apt is broken based on cross-installation problems. That's like trying to put Ford truck parts on your Chevy truck. Sure they are both trucks and sure some parts might go in fine but sooner or later you are going to have problems. If the Debian based distro suggests that you do this and then is broken then I would say that is the fault of the managers of the Debian based distro, not the fault of Debian, not the fault of apt, not the fault of the Debian repositories. "Debian based" != Debain. "Debian based" ~ Debian. I guess that's why I run plain old Debian. The only exception to that might be a specialized Debian based distribution like Knoppix. I don't know, maybe I'm off base here but I don't think so.

Also, I don't want to sound like I have *never* had a problem because that would be a lie. I can tell you that the number of problems I have ever run into with apt and repos on the real deal Debian can easily be counted on one hand, all of them were easily resolvable, and if I recall correctly most of them had something to do with me trying to install something from the unstable branch.

Ice9 · Post by **Ice9** » Thu Dec 09, 2004 12:09 pm

Now, Debian itself has a vast amount of software out there, more than any other distro so I know it would surely be tempting to just point at those repos and install away but I don't see how one could complain tha Debian or apt is broken based on cross-installation problems. That's like trying to put Ford truck parts on your Chevy truck.

I totally agree with you on this.
The problem, I think, is that these Debian-based distros all have a couple of repositories of their own and next to that they all point to various other Debian repositories, and often mixing tesing and unstable repositories.

this is my sources.list from Mepis for instance (I didn't add anything in there)

Code: Select all

# See sources.list(5) for more information, especialy

# This file may be edited by the MEPIS System Center
# Do not modify the comments manually!
# Change sources only in the section at the end of this file!

# Primary
deb ftp://ftp.us.debian.org/debian/ testing main contrib non-free 
# deb-src ftp://ftp.us.debian.org/debian/ testing main contrib non-free 
deb ftp://ftp.us.debian.org/debian/ unstable main contrib non-free 
# deb-src ftp://ftp.us.debian.org/debian/ unstable main contrib non-free 

# non-us
deb ftp://non-us.debian.org/debian-non-US/ testing/non-US main contrib non-free 
# deb-src ftp://non-us.debian.org/debian-non-US/ testing/non-US main contrib non-free 
deb ftp://non-us.debian.org/debian-non-US/ unstable/non-US main contrib non-free 
# deb-src ftp://non-us.debian.org/debian-non-US/ unstable/non-US main contrib non-free 
# deb http://download.videolan.org/pub/videolan/debian/ sid main  

# MEPIS cds
# deb file:/mnt/cdrom/ testing main 

# MEPIS pool - specific packages available on-line
deb http://2004.mepis.org/mepis/ testing main 

# DO NOT EDIT ABOVE THIS LINE
# mplayer
deb ftp://ftp.nerim.net/debian-marillat/ unstable main 
# java
# deb ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/debian/ unstable main non-free