You are not logged in.
Pacman 3 is now real, thanks to the developers for making this a possibility, as I were the first in criticizing for pacman 3 being such a slow developing piece of software, now I want to be the first to demonstrate my gratitude. It feels a bit more alive, and more interactive, being more verbose, for example now is not just pacman -Scc and your cache is cleaned without any output message, now this command asks you if you really want to clean your cache. I advise anybody to start testing it has shown to be very reliable.
I was almost banned a few months ago for my constant critique against pacman 3 development, since Frugalware had pacman 3 ready for months now, but well, maybe Arch Linux devs never saw pacman 3 as an urgent update. So all in all keep up the great work.;)
Offline
Please be careful if you are going to test this guys- I would really recommend you hold off until our next RC, which is coming very soon, unless you have been following pacman development for a while. It isn't that the software is unstable, but we have fixed a few known bugs in this version and haven't released the changes yet (they are just in CVS).
On the same note, we have been working on pacman 3 for a long time because we want to make sure it is as stable as possible, and released with hopefully as few bugs as possible. Because pacman 2.9.8 was and still is a relatively solid version, we didn't want to have an upgrade cost anyone the stability that the older version had.
Offline
Oi. Well this is a shade sudden. We were trying to phase in public testing due to the many code changes (not necessarily functional changes). The progress path was pacman-dev list -> arch mailing list -> forums -> news announcement -> testing -> current.
Anyway, it's about time we did move along. Please do take toofishes' advice and hold off a bit for our next RC, unless you know what you're doing.
Offline
Could someone explain some of the differences between pacman 2.x and 3? On the webiste, all that was mentioned was that pacman3 is a libified version. What does that mean? What are some other features?
Thanks
Offline
Could someone explain some of the differences between pacman 2.x and 3? On the webiste, all that was mentioned was that pacman3 is a libified version. What does that mean? What are some other features?
Thanks
"libified" means a lot of the functionality is now in a separate library so people can easily build other front-ends.
As for the features, a pacman dev could answer better than I could, but here's what I've heard:
(a) It's faster (lots faster)
(b) The code is cleaner
(c) The exciting new features are coming in pacman 3.1
It's basically like KDE 4. The infrastructure is cleaner so it works better and is easier to hack on, but the flashy stuff will have to wait for the point releases.
Last edited by skymt (2007-03-10 19:56:08)
Offline
[url=http://www.archlinux.org/pipermail/pacman-dev/2007-March/001942.html]I was almost banned a few months ago for my constant critique against pacman 3 development, since Frugalware had pacman 3 ready for months now, but well, maybe Arch Linux devs never saw pacman 3 as an urgent update. So all in all keep up the great work.;)
Well, Frugalware's pacman3 was slightly different and not the same landmark.
But yes finally its here or really really close
Offline
Wow, it's really much faster now.
No problems at all so far (rankmirror is useful as well, now using only 5 european mirrors instead of ... something in top of the list)
Offline
Would you like to give a changelog from 2.x to 3.0 ?
Offline
A good advice: wait for next RC.
My $HOME wad deleted thanks to makepkg3 -> http://bugs.archlinux.org/task/6553
Pacman needs to be more tested !
Last edited by wain (2007-03-11 10:55:43)
Offline
A good advice: wait for next RC.
My $HOME wad deleted thanks to makepkg3 -> http://bugs.archlinux.org/task/6553Pacman needs to be more tested !
hmmm, that was serious, now we have to fear makepkg3:(
Offline
hmmm, that was serious, now we have to fear makepkg3:(
Or just toofishes , but it is fixed in now in CVS so waiting till the next RC or just not using makepkg -C until the next RC is suggested.
Offline
Hello,
Pacman development was not slow, it just had a lot of changes. Besides, there were fixes and releases for the 2.x series.
To the features mentioned:
>(a) It's faster (lots faster)
I can't confirm this. Remember the discussion on the dev list alpm_list missing ->prev, with the profile attached.
More memory efficient, except the pre allocated strings and similar. It has not gotten worse than before, but also the feeling at calculating huge package depends (measured using time) was about 1-2 secs up and on at 20-30 secs waittime.
>(b) The code is cleaner
Well, cleaner. It has some unclean "you usually don't do this" things in, but they actually provide some speed, as the macros used, the jumpmarks (some of them are not necessary though).
>(c) The exciting new features are coming in pacman 3.1
*sigh* always the next release .
Personally i wish i had never looked at the pacman code . I also dislike some code style (memory allocation of some parts between pacman and the lib), but that's style and design, and it obviously is as designed. I've been working in scientific c/c++ development for over 6 years (face recognision, pattern recognition, encrypted memory filesystems, firewire camera implementations), some years ago though, but sometimes i could crash my head against the table by reading. On other parts i'm impressed by the thoughts of the developers in some pacman parts. Cold-warm shower, but i'm not the one to critism pacman - as long as it does its job. The developers spend their spare time in pacman, and i'd spend all of them an eve' beer if they ever visit Vienna.
The (for me) great points in pacman3 are:
- libdownload - a stand alone download lib for pacman, with proper proxy support. Looks a bit nicer, especially for people who used proxy with wget before... and for some reason it seems faster at proxy connect.
- libalpm - the pacman library. Fine, finally there might be some more user interfaces, since it simpilfies the gui development alot. I'm missing the c++ interface, but i threw away my plans on pacman++ by watching my time tables at other projects.
Ability is nothing without opportunity.
Offline
I'm missing the c++ interface, but i threw away my plans on pacman++ by watching my time tables at other projects.
I've debated c++ a few times, as I'm a c++ fanboy, and it would clean up quite a few messy parts....
Offline
I'm very excited about libalpm. It doesn't just simplify GUI development, but development in general!
"Your beliefs can be like fences that surround you.
You must first see them or you will not even realize that you are not free, simply because you will not see beyond the fences.
They will represent the boundaries of your experience."
SETH / Jane Roberts
Offline
There is second Rc around, by the way. Certainly not intended for productive purposes, and those bound for testing will know where to find it.
Offline
As tlaloc stated, we released a second RC today, so use it rather than the first. If you want to use it, you will have to go browse the archives of the pacman-dev mailing list, or better yet, join the mailing list so you can either report bugs or tell us everything is good (we really like to hear the latter as well because it lets us know people are actually out there testing it).
Offline
STiAT wrote:I'm missing the c++ interface, but i threw away my plans on pacman++ by watching my time tables at other projects.
I've debated c++ a few times, as I'm a c++ fanboy, and it would clean up quite a few messy parts....
I fully aggree with you in this case, but it would require a completely new alpm and pacman design.
It would ease the memory handling due to having destructors, the cleanup jumps and similar would disappear. The allocation would be easier, and more dynamic, so less memory would be used (in cost of some speed of course).
List iterators might also ease list handling and depend checking... maybe not ease, but at least it would ease the code reading part, since i guess the algorithms used are quite fine.
Also i think using similar as sqllite would be by far easier and faster for depend calculation than the current go to dir open file depends look depends and go into dirs and check again method, especially when doing this on the same db handle on a local file... databases simply are faster.
Will try the new rc... have to annoy you with all those bugs which hopefully are not in .
Ability is nothing without opportunity.
Offline
Hi, any idea how can i run rankmirrors??
Offline
Try
rankmirrors -v
against a file in /etc/pacman.d
To speed it up a little, you should remove all mirrors from other continents in these files first
Offline
Finally i did # rankmirrors /etc/pacman.d/testing (for example) and it worked fine
Offline
pacman 3 seems much more faster than it used to be, I'm glad for that matter. I don't care how long we waited for pacman 3, it was well worth it in my opinion. Pacman is probably one of the biggest reasons I fell in love with arch. This piece of software makes my life much more easier.
Offline
agreed.. pacman is a big part of why I love arch also, I'm glad it wasn't rushed.. why ruin a good thing or an important thing at that?
Offline
removed NoUpgrade lines from default pacman.conf
Why exactly is this? Does this mean I can remove them from my existing pacman.conf or not?
Thanks.
Offline
removed NoUpgrade lines from default pacman.conf
Why exactly is this? Does this mean I can remove them from my existing pacman.conf or not?
Thanks.
All files listed in NoUpgrade are now properly handled by their respective packages. In addition, pacman 2.X had a little issue where adding a backup=() file took 2 package upgrades to take effect - that is, the first upgrade saved the new "backup" setting, but didn't act on it. pacman 3 now acts on this.
Offline