You are not logged in.
Pages: 1
Howdy all, I was asked to create the archlinux backend for smart package manager and I am making good progress.
For right now, it will not include support for the AUR, though I am planning that for the future.
smart forum post
smart homepage
launchpad branch
my blog post
Current issues at hand:
08/02/08 - smart's builtin fetcher object not fetching db files, so Ill have to create a custom one.
08/02/08 - no pkgbuild atm - will not be released until everything works
comments/questions/suggestions welcome
EDIT: my site is back up
Last edited by platinummonkey (2008-08-04 02:23:46)
Offline
I'm not really familiar with this, but from what I see it's like a unified frontend for multiple package backends? Interesting. Are you using libalpm?
[git] | [AURpkgs] | [arch-games]
Offline
a unified frontend for multiple package backends?
Yes, I would say that is a fairly accurate statement.
Are you using libalpm?
at the moment no, it will eventually migrate to something of that nature. The docs on libalpm are ... well hardly existant, so its programmed to fetch the db file and create its own list of available packages (voids the use of packages.txt) and obtain the information in that gzipped file from the desc and depends lists.
Offline
a unified frontend for multiple package backends?
Yes and no.
What smart does is it's a front end to the systems default package manager. Such as rpm, dpkg, pkgtools, and now libalpm. What smart offers is a better algorithm in which to solve dependencies.
If you wish to read up on it, the revised documentation (a work in progress) is here. There is also the smart home page, which also includes an FAQ, Features, and config options (which do not yet contain the config options for the archlinux backend). I think the FAQ's will anser most of your questions.
Offline
It's been a few years since I've used the Smart Package Manager, but I do remember that when I came to Arch I couldn't believe how much better pacman was. But, as I said, that was a few years ago. My question here is, how can Smart be better than pacman for Arch? (This is not a sarcastic question, I really want to know.)
Offline
It depends on your definition of "better"... I am going to say this in the most unbiased way I can:
Think of it not as a replacement; but, as an alternative method of package management. Smart determines dependency issues, package installation order in a different way, something that all package managers tend to do in their own respect. One thing to note about smart is that it also has the ability to find the fastest and most reliable mirrors for you, holds package/mirror priorties, for example, kernel upgrades and xorg upgrads are of high priority no? Smart gives you the ability to take advantage of making certain packages and mirrors of higher priority over other packages. It will eventually for arch include mirrorlist support, but I am still developing this at the moment.
You can use smart with the command line or with the gui, as with most other package managers; so once again its all a matter of preference. It's another alternative to possibly meet your computing needs
Offline
It's been a few years since I've used the Smart Package Manager, but I do remember that when I came to Arch I couldn't believe how much better pacman was. But, as I said, that was a few years ago. My question here is, how can Smart be better than pacman for Arch? (This is not a sarcastic question, I really want to know.)
It really has to do with the algorithm. For me to explain that, would involve getting into the python code. I am a novice at python, so explaining all that would be a bit over my head. The same could be said of rpm or dpkg or any other. See, over the years there have been many package managers, and the evolution of package managers. Each have their own benefits, but they all were just overlays of the systems package management, and really didn't deal with the issue. That has historically been left up to, in the case of rpm, rpmlib and the packager. rpmlib is called upon the check provides, requires, depends, and obsoletes, and ofcourse this is all the job of the packager to properly handle those. So now enters smart on the scene. Smart changed all that by changing the algorithm, and part of it involves reordering. It's an rpm option, that is generally unknown and not used. Smart does allow you to turn off the algorithm, in which case it becomes just another overlay for the systems package manager.
I started out with Slackware 7.1, and have used a variety of rpm distros, but have also used a few deb distros. I have also done Sabayon Linux, so I am familiar with portage as well. I was called up, some time ago, to code the backend for ArchLinux. So I read up on pacman. Lots of config options. A truly nice tool. I, however, found platinummonkey, who had more experience at python, and was already familiar with ArchLinux. So I introduced smart to him, and asked him to code the backend.
I continue to study python, but until I get a whole lot better at python, and learn C, this is as far as I can explain the algorithm. Actually, I have my hands full. I'm learning Glade, GTK+, python, and pygtk, all at once. I do realize Glade is a RAD. Glade itself isn't hard. It's knowing GTK+, which is funny since knowing GTK+ requires knowledge of C. So I'm in deep.
Feel free to review the code. http://bazaar.launchpad.net/~smartpm/smart/trunk/files
Offline
It depends on your definition of "better"... I am going to say this in the most unbiased way I can:
Think of it not as a replacement; but, as an alternative method of package management. Smart determines dependency issues, package installation order in a different way, something that all package managers tend to do in their own respect. One thing to note about smart is that it also has the ability to find the fastest and most reliable mirrors for you, holds package/mirror priorties, for example, kernel upgrades and xorg upgrads are of high priority no? Smart gives you the ability to take advantage of making certain packages and mirrors of higher priority over other packages. It will eventually for arch include mirrorlist support, but I am still developing this at the moment.
You can use smart with the command line or with the gui, as with most other package managers; so once again its all a matter of preference. It's another alternative to possibly meet your computing needs
First off, I fully support the efforts to do this; more choices are always a good thing in software. The following is for conversation, not argument.
kernel and xorg upgrades are treated with the same priority as everything else that's being upgraded: 'it's on the mirror lists now, upgrade it'. If you don't want it, block it. Rank mirrors will set up priorities for servers. Etc...
This is why I was wondering if Smart had something more (not just different) to offer than pacman. On a non-rolling release like Mandriva (where I used Smart before), it was a gift from the Gods. But with Arch I'm really not sure if or how it can improve on what's either already in place or what's coming down the pipe.
Last edited by skottish (2008-08-04 03:12:48)
Offline
point taken
In pacman you can hold/ignore packages with the pacman.conf, which is very useful. This does something very similar with just more to it, deeper priorites and package preferences. So instead of just i want it/or I don't want it, there is I want this more than that, and that more than this other package, and this is more important than these, and packages from this repo are more important than packages from that other repo, etc.. Keeping a "point-like scale" on repo statistics has the ability to greatly speed up upgrade times by finding the fastest and most reliable server for you.
Some might consider it a blessing, other will still prefer pacman/another package manager.
to be honest, i still use pacman, thats just the way ive always have used arch and the way i like it (with yaourt for the aur at times). I could use my system only through the command line, and I do occasionally for a couple weeks here and there (ask any USALUG member
); alhough, I see why some people might benefit from this and prefer smart (not just for its gui interface), which is really why I took on this project.
Side note: libalpm project in pacman-git I really do plan on incorporating libalpm; but, for someone who hasn't touched C in over 7 years, its a little doozy
Offline
So instead of just i want it/or I don't want it, there is I want this more than that, and that more than this other package, and this is more important than these, and packages from this repo are more important than packages from that other repo, etc..
I like arch, because arch Keeps It Simple, Stupid!
good luck
Offline
the options are there, its whether you use them or not to their advantage
I like arch, because arch Keeps It Simple, Stupid!
good luck
me too kiss ftw!
and thanks
Last edited by platinummonkey (2008-08-04 16:46:49)
Offline
Pages: 1