Pacman vs SmartPM

closet geek · 2007-02-21 12:10:36

Hi,

Apologies for being so demanding in my first post! I'm a debian user who has got kind of sick of apt/aptitude not living up to the billing and breaking my system on upgrades, package removals etc. I'm therefore in the hunt for a system that I can stay with for the long term. Can anyone give some detail on how Pacman compares to SmartPM? Technical explanations or simply end user anecdotes are fine. I notice for example that there hasn't been a stable release of Pacman since 02/02/2006 - this could imply that there is no need for more frequent releases as Pacman is already so good or indeed that it is a bit neglected?

Of course asking this on the Arch forums might seem silly but I'm judging from what I read so far during my lurk phase this place doesn't seem to contain the rabid fanboys that the other, larger, distros seem to encounter so I'm hopeful of some frank analysis! I quote my first line for those that have forgotten it "apologies for being so demanding in my first post"

cg

Susu · 2007-02-21 12:58:42

I'm not much into SmartPN so it's a bit hard to compare, but you should have a look at http://wiki.archlinux.org/index.php/Pacman (incl. Related Links) and maybe you're interested in yaourt, a nice wrapper for pacman with support for AUR/ABS pkgbuilds and so on.

closet geek · 2007-02-21 14:56:30

Thanks for the yaourt link, that's something I'd not found in previous searches. It's nice to see community additions such as this!

Just to clarify: I'm not interested in Smart's ability to use deb/rpm/etc repositories I'm more interested in its ability to resolve dependencies reliably without breaking a system compared to Pacman's ability in said tasks. I could always try both myself, but if someone has already done this and would like to share their experiences it certainly would save me the effort

cg

tomk · 2007-02-21 15:03:55

I've never heard of SmartPM, I have to admit, and I've certainly never come across anyone using it on Arch. That's for your own information, so you can put the following in context.

pacman is purpose-built to meet the requirements of Arch Linux, something it does very well. Apart from the wiki page referred to above, the man page is also worth a look. However, IMO you will only be in a position to make comparisons after you have used it for a while.

Regarding development, pacman 3 is under intensive development right now. Limited rc releases have been completed, and we expect to have it in the Arch testing repo soon.

On a more general note, there are other reasons for choosing a distro apart from the package management system. I'd suggest you have a good browse around the forum, wiki, and MLs to give yourself as much background as possible before installing.

closet geek · 2007-02-21 15:50:11

tomk wrote:

pacman is purpose-built to meet the requirements of Arch Linux, something it does very well. Apart from the wiki page referred to above, the man page is also worth a look. However, IMO you will only be in a position to make comparisons after you have used it for a while.
Regarding development, pacman 3 is under intensive development right now. Limited rc releases have been completed, and we expect to have it in the Arch testing repo soon.
On a more general note, there are other reasons for choosing a distro apart from the package management system. I'd suggest you have a good browse around the forum, wiki, and MLs to give yourself as much background as possible before installing.

I have taken a look through both Wiki and man page previously, but this really only presents the theory of the whole process! I guess I'm looking for real world results/analysis. I guess SmartPM isn't that well known but I think Shuttleworth is now financing the lead developer so it might find its way into Ubuntu at some point. This suggests to me that it probably has decent potential.

Ahh, that's music to me ears (or indeed, to my eyes): "pacman 3 is under intensive development right now". I appreciate there are other factors to consider but I've already given Arch the thumbs up in other departments (rc.conf, minimal, great community where devs can be found, etc) so my choice does come down to the quality of the package manager now. I'm strange: I don't mind fixing things, tweaking my installs etc but I get very annoyed when I do a dist-upgrade and my system gets broken. That's one aspect of my OS experience that I would much rather "just work". Or at least, "just work" more often than apt-get does now.

I'm encouraged by the helpful responses I've had so far, thanks a lot! Can't wait to try Pacman out. More opinions welcome of course

cg

skottish · 2007-02-21 21:29:50

I used Smart Package Manager for well over a year with Mandriva, and it's a nice package mananger. In my opinion, it brings nothing to the table that Pacman doesn't. The way the package is, well, packaged determines if a good package manager does it's job.

closet geek · 2007-02-21 21:45:25

skottish: thanks for that. It's good to hear from someone with experience of both tools. Am I correct to infer you've had no more problems with pacman than you did with smart?

cg

skymt · 2007-02-21 21:59:10

closet geek wrote:

I'm strange: I don't mind fixing things, tweaking my installs etc but I get very annoyed when I do a dist-upgrade and my system gets broken. That's one aspect of my OS experience that I would much rather "just work". Or at least, "just work" more often than apt-get does now.

Honestly, Arch doesn't do that. It's not the package manager (I've yet to run into a conflict of any sort), it's the packages. Things change, things break, and often the only way to prevent breakage on your own system is to read the home page news before each upgrade.

Example 1: The Nvidia packages were recently reorganized. Previously, the user could choose between nvidia (9000-series) and nvidia-legacy (7000-series, but supports older cards). Nvidia removed some cards from their support list and now maintain two different series of legacy drivers (71xx and 96xx) in addition to the 97xx current series. In Arch, users of the nvidia-legacy drivers got switched to nvidia-71xx, which is fine. But users with cards that are no longer supported by the current drivers found themselves with broken systems the next time they tried to start X. The only warning was this news post.

Example 2: Arch switched to a new system for generating the initrd. The changeover moved a few essential files around, and left users to update their grub configuration. If they don't, they get a kernel panic next time they boot. pacman prints a warning about this when it does the upgrade, but if a user is doing their first update after a fresh install it can get lost in the flood of output.

Other examples: dbus, hwdetect, screen/ncurses.

Last edited by skymt (2007-02-21 22:05:27)

cactus · 2007-02-21 22:04:14

closet geek: Not sure if you found this link in your searches yet.
http://cactuswax.net/blog/articles/2007 … eview.html

I wrote it as a brief overview of some of the 'deeper functionality' of archlinux.

....

In answer to your question about dependency handling, pacman is pretty good...it is also pretty simple. Because arch is a rolling release system, you often have the most recent libraries installed. This generally makes it easier to upgrade packages that depend on newer versions of libraries. You don't often (but you sometimes do) run into apps that require old versions of some library, without working with newer ones. In those cases, you can often find older versions of the library and install them, or build your own packages for them (making your own package is easy compared to making debs or rpms).

skottish · 2007-02-21 22:10:11

closet geek wrote:

skottish: thanks for that. It's good to hear from someone with experience of both tools. Am I correct to infer you've had no more problems with pacman than you did with smart?
cg

I had more problems with Smart. It was fairly unstable the last time I used it (crashes were common). As far as basic functionality goes, the only problem that I've had with either is getting to them when mirrors are syncing. That's always tricky.

There is one thing to note with my experience with Smart: I was commonly loading Cooker software on a stable branch of Mandriva. I use to get serious breakages that I couldn't undo... whoops!

toofishes · 2007-02-21 22:44:42

closet geek wrote:

I notice for example that there hasn't been a stable release of Pacman since 02/02/2006 - this could imply that there is no need for more frequent releases as Pacman is already so good or indeed that it is a bit neglected?

My first response is that pacman is quite stable as of this release (02/02/2006), and thus had no crucial updates needed. At this point, development did shift to pacman3, which is a libified version, so not much work was put into the old code. This is not to say it was perfect- it has its shortcomings but overall it is a very reliable piece of software, and 99% of errors when upgrading can be chalked up to packaging errors.

As others have said, pacman 3 is coming very soon- besides a different code structure (which is mostly transparent to the user), we have been working to close many of the bugs reported in Flyspray, our bug tracking system. Just yesterday we ran a full test suite of about 71 different package scenarios, and they all passed. We plan on adding even more tests in the future to make sure pacman does what it is supposed to do consistently.

If you are real interested in pacman, you may want to take a look at the mailing list, accessible though the front page.

closet geek · 2007-02-21 23:04:06

skymt wrote:

Honestly, Arch doesn't do that. It's not the package manager (I've yet to run into a conflict of any sort), it's the packages. Things change, things break, and often the only way to prevent breakage on your own system is to read the home page news before each upgrade.
Example 1: The Nvidia packages were recently reorganized. Previously, the user could choose between nvidia (9000-series) and nvidia-legacy (7000-series, but supports older cards). Nvidia removed some cards from their support list and now maintain two different series of legacy drivers (71xx and 96xx) in addition to the 97xx current series. In Arch, users of the nvidia-legacy drivers got switched to nvidia-71xx, which is fine. But users with cards that are no longer supported by the current drivers found themselves with broken systems the next time they tried to start X. The only warning was this news post.
Example 2: Arch switched to a new system for generating the initrd. The changeover moved a few essential files around, and left users to update their grub configuration. If they don't, they get a kernel panic next time they boot. pacman prints a warning about this when it does the upgrade, but if a user is doing their first update after a fresh install it can get lost in the flood of output.
Other examples: dbus, hwdetect, screen/ncurses.

When I first read your post it seemed to put pacman in a bad light, however it's clear to me now that this is not the case and my first reaction was simply wrong. Every issue you linked to is in fact a new article published on the front page of the site. I think that speaks volumes of the team here. I also like the fact Pacman produces a warning - I've only got myself to blame if I ignore that and my system is borked. Lastly, I may well be using "pacman" (the name) incorrectly here: it seems all of these changes would have have caused the same issues no matter what packaging system was in use.

cg

closet geek · 2007-02-21 23:07:19

cactus wrote:

closet geek: Not sure if you found this link in your searches yet.
http://cactuswax.net/blog/articles/2007 … eview.html
I wrote it as a brief overview of some of the 'deeper functionality' of archlinux.
....
In answer to your question about dependency handling, pacman is pretty good...it is also pretty simple. Because arch is a rolling release system, you often have the most recent libraries installed. This generally makes it easier to upgrade packages that depend on newer versions of libraries. You don't often (but you sometimes do) run into apps that require old versions of some library, without working with newer ones. In those cases, you can often find older versions of the library and install them, or build your own packages for them (making your own package is easy compared to making debs or rpms).

Thanks for that, you'll hopefully be pleased to hear that I already found your article earlier today. It summarised the key benefits of Arch well!

Your second point is something I'd not taken into account before. It's a good point at that! If I simply waited would a package appear on AUR in these kind of situations? I guess it depends on the popularity of the piece of software I'm trying to install. Food for thought!

cg

closet geek · 2007-02-21 23:09:31

skottish wrote:

I had more problems with Smart.

...is what I wanted to hear! Thanks for your help, it's really useful to get feedback from others that have used both and are able to compare objectively

cg

closet geek · 2007-02-21 23:14:39

toofishes wrote:

My first response is that pacman is quite stable as of this release (02/02/2006), and thus had no crucial updates needed. At this point, development did shift to pacman3, which is a libified version, so not much work was put into the old code. This is not to say it was perfect- it has its shortcomings but overall it is a very reliable piece of software, and 99% of errors when upgrading can be chalked up to packaging errors.
As others have said, pacman 3 is coming very soon- besides a different code structure (which is mostly transparent to the user), we have been working to close many of the bugs reported in Flyspray, our bug tracking system. Just yesterday we ran a full test suite of about 71 different package scenarios, and they all passed. We plan on adding even more tests in the future to make sure pacman does what it is supposed to do consistently.
If you are real interested in pacman, you may want to take a look at the mailing list, accessible though the front page.

A reply from another developer, this time a developer of the software I was asking about. Wow! I'm impressed here. If this the Arch way I think you've found a convert!

I think the dev lists might be a smart idea, I'll no doubt find the technical side of things thrashed out there. I've not even used pacman 2, yet I'm still excited to hear that v3 is close to completion. I guess my question would be: is v3 stable enough to use for a daily Syu? Passing all the tests would seem to indicate a yes... maybe I should just be patient

cg

skymt · 2007-02-21 23:46:45

closet geek wrote:

When I first read your post it seemed to put pacman in a bad light, however it's clear to me now that this is not the case and my first reaction was simply wrong. Every issue you linked to is in fact a new article published on the front page of the site. I think that speaks volumes of the team here. I also like the fact Pacman produces a warning - I've only got myself to blame if I ignore that and my system is borked. Lastly, I may well be using "pacman" (the name) incorrectly here: it seems all of these changes would have have caused the same issues no matter what packaging system was in use.
cg

I didn't mean to say anything bad about pacman. The first point I made was that the problem lies with the packages.

The main point of my post is that Arch will break if you update blindly without checking for news (which you seem to do, reading between the lines). Debian seems to do better with that, with systems in place to automatically update configuration files. If Arch had Debconf, we would never have had the mkinitcpio mess in the first place.*

It would be nice if pacman would always warn about pitfalls. It did about mkinitcpio, but AFAIK said nothing during the nvidia upgrade.

* That's not to say Arch should use Debconf. I like it the way it is, thank you.

Last edited by skymt (2007-02-21 23:47:23)

closet geek · 2007-02-21 23:56:51

You are correct, I do update assuming (hoping) there will be no issues! *goes to check if any debconf discussions have taken place in the past*.

It's a shame that there was no warning, but I guess the nvidia issue could have slipped under the radar as only some cards would have been affected but the mkinitcpio issue affected everyone.

cg

hacosta · 2007-02-22 03:31:54

so yeah in my experience arch has been very stable regarding updates, and im yet to have a dependency issue using the standard repos, you should be fine if you read the output of pacman after installing, ie dont put pacman in cron

platinummonkey · 2008-08-03 02:51:57

http://bbs.archlinux.org/viewtopic.php? … 99#p401399

Smart package manager support for archlinux ^_^

venky80 · 2008-08-03 07:02:36

I have only one questions regarding package managers, there are shit load of them all over the place , but not even one of them guarantees that it will restore the machine to the same state when the package was not installed.
Meaning suppose package A is there is the repository...I install Package A using whatever package manager apt, rpm, pacman whatever then I uninstall package A, my machine is not in the state when I never had package A installed, some shit is left behind.
People always tell me f you change config files etc etc, but there should be an option for me to tell the package manager to take all the crap associated with package A with it, yes I know if I change the config then I own it, but I want the package manager to be smart...but whatever ..other than this I think pacman is pretty neat and I love Arch.

attila · 2008-08-03 11:52:13

tomk wrote:

I've never heard of SmartPM, I have to admit, and I've certainly never come across anyone using it on Arch.

SmartPM is a frontend for certain package managers and you have to see it as example lightly the same as aptitude for debian.

I use it on my opensuse server and it is my first option if i test some other distros in a virtuell machine. The big advantage is that you have to know or to learn only one syntax. So offering support for pacman in SmartPM would be even a plus but never a replacement and this could be very nice for people who change or switch.

Daenyth · 2008-08-03 13:52:06

venky80 wrote:

I have only one questions regarding package managers, there are shit load of them all over the place , but not even one of them guarantees that it will restore the machine to the same state when the package was not installed.
Meaning suppose package A is there is the repository...I install Package A using whatever package manager apt, rpm, pacman whatever then I uninstall package A, my machine is not in the state when I never had package A installed, some shit is left behind.
People always tell me f you change config files etc etc, but there should be an option for me to tell the package manager to take all the crap associated with package A with it, yes I know if I change the config then I own it, but I want the package manager to be smart...but whatever ..other than this I think pacman is pretty neat and I love Arch.

You are looking for pacman -Rn

rooloo · 2008-08-03 13:54:14

venky80 wrote:

I have only one questions regarding package managers, there are shit load of them all over the place , but not even one of them guarantees that it will restore the machine to the same state when the package was not installed.
Meaning suppose package A is there is the repository...I install Package A using whatever package manager apt, rpm, pacman whatever then I uninstall package A, my machine is not in the state when I never had package A installed, some shit is left behind.
People always tell me f you change config files etc etc, but there should be an option for me to tell the package manager to take all the crap associated with package A with it, yes I know if I change the config then I own it, but I want the package manager to be smart...but whatever ..other than this I think pacman is pretty neat and I love Arch.

man yaourt

http://aur.archlinux.org/packages.php?ID=5863

CLEANING OPTIONS
-c * delete all .pacsave/.pacnew files
d, --database *
clean database (show obsolete repositories)
REMOVE OPTIONS
-c, --cascade
remove packages and all packages that depend on them
-d, --nodeps
skip dependency checks
-k, --dbonly
only remove database entry, do not remove files
-n, --nosave
remove configuration files as well
-s, --recursive
remove dependencies also (that won't break packages)
Note: yaourt always shows new orphans after package removal

if pacman can't do it, a pacman wrapper sure can!!!!

Last edited by rooloo (2008-08-03 13:55:00)

venky80 · 2008-08-04 08:07:25

so how would be the option be used with yaourt?

Arch Linux

#1 2007-02-21 12:10:36

Pacman vs SmartPM

#2 2007-02-21 12:58:42

Re: Pacman vs SmartPM

#3 2007-02-21 14:56:30

Re: Pacman vs SmartPM

#4 2007-02-21 15:03:55

Re: Pacman vs SmartPM

#5 2007-02-21 15:50:11

Re: Pacman vs SmartPM

#6 2007-02-21 21:29:50

Re: Pacman vs SmartPM

#7 2007-02-21 21:45:25

Re: Pacman vs SmartPM

#8 2007-02-21 21:59:10

Re: Pacman vs SmartPM

#9 2007-02-21 22:04:14

Re: Pacman vs SmartPM

#10 2007-02-21 22:10:11

Re: Pacman vs SmartPM

#11 2007-02-21 22:44:42

Re: Pacman vs SmartPM

#12 2007-02-21 23:04:06

Re: Pacman vs SmartPM

#13 2007-02-21 23:07:19

Re: Pacman vs SmartPM

#14 2007-02-21 23:09:31

Re: Pacman vs SmartPM

#15 2007-02-21 23:14:39

Re: Pacman vs SmartPM

#16 2007-02-21 23:46:45

Re: Pacman vs SmartPM

#17 2007-02-21 23:56:51

Re: Pacman vs SmartPM

#18 2007-02-22 03:31:54

Re: Pacman vs SmartPM

#19 2008-08-03 02:51:57

Re: Pacman vs SmartPM

#20 2008-08-03 07:02:36

Re: Pacman vs SmartPM

#21 2008-08-03 11:52:13

Re: Pacman vs SmartPM

#22 2008-08-03 13:52:06

Re: Pacman vs SmartPM

#23 2008-08-03 13:54:14

Re: Pacman vs SmartPM

#24 2008-08-04 08:07:25

Re: Pacman vs SmartPM

Board footer