You are not logged in.
Pages: 1
Dear Forum!
I am thinking of switching to archlinux, however before I do, I still have some questions. ![]()
1) How does arch's "rolling release" approach handle big incompatible rev bumps of libraries or gcc? I have been using Gentoo (a source based distro with rolling releases) for years and in such cases a rebuild of all affected packages was required (in case of the gcc3 to gcc4 transition, a rebuild of the whole system). To my understanding in such a case with arch an updated version of all affected binary packages must be released simultaneously to the library/gcc update. Is this properly coordinated or do things break?
2) How mature is arch for x86_64 regarding package selection and 32bit compatibility? Are 32bit versions of important libs like GTK2 or Qt available as an arch package?
3) Can I install 32bit closed source software like Adobe Reader, Google Earth and Adobe Flash using pacman and get automatic updates? Or do I have to pull some "force architecture" stunt that breaks automatic updates or install the software on arch64 by hand?
4) Can I install (for example by using a special repository) things that are legally problematic in some countries, like MP3 support, 64-bit-WMW codecs, DeCSS etc. via pacman and receive automatic updates for them?
5) Quite frankly: How good is package QA? ![]()
Sorry for not looking up the availability of 64bit packages myself, but as it seems the web interface of the package database doesn't show me the architectures for which a package is available.
Thanks in advance!
Regards,
Stefan
Offline
ad 1)
I have never experienced inconveniences concering the binaries and gcc. After updating gcc, the packages, which were (probably) built against an older version of gcc continued working without a problem. So nothing of a hassle here.
ad 2 & 3)
I would still suggest to use i686, the advantages of x86_64 are outperformed by the inconveniences. Arch is very streamlined. If you go 64 bit, you are supposed to let go of all 32bit-only apps, as they do not support the architecture you run natively.
ad 3 & 4)
CSS and legally problematic software has never been a problematic issue concerning Arch. Just install it and enjoy bleeding edge quality packages.
ad 5)
The package quality is good, but sometimes there's some delay in releases - but I do not know if I understood your question correctly.
celestary
Intel Core2Duo E6300 @ 1.86 GHz
kernel26
KDEmod current repository
Offline
3 + 4.) Yes you can! A quck 'pacman -S codecs acroread flashplugin' will get you that stuff, and have auto updates. For google earth, there is a package in the AUR[1]. Arch's user repository.
5.) Q/A I think is really good. Important packages such as the kernel and X11 are in the testing repository right now, so the bugs can get worked out.
I'm not 100% sure on 1 and 2 though. If you decide to try Arch, have fun! ![]()
Offline
1.) Rebuilds like that are very rare... gcc3->gcc4 is the only instance that I know of. If I remember correctly, they got all of the packages ready in testing, and once it looked like everything was working, they moved them all to current+extra at once, and asked people to hold off while the mirror were updating.
I waited a week to be safe, but from my end it was just a 'pacman -Syu' and reboot.
Edit: part2,
The devs do something similar for kernel 2.6.n -> 2.6.n+1 releases (Also the python 2.4 -> 2.5). If you check out the testing tree right now, you'll see they're getting all of the kernel drivers/modules ready for 2.6.22. Once they consider that set usable, they'll move it to current.
Last edited by jb (2007-07-17 20:49:13)
...
Offline
I would still suggest to use i686, the advantages of x86_64 are outperformed by the inconveniences. Arch is very streamlined. If you go 64 bit, you are supposed to let go of all 32bit-only apps, as they do not support the architecture you run natively.
x86-64 is perfectly able to run 32bit-x86 software natively (see http://en.wikipedia.org/wiki/Long_mode), I have been doing it for years. However, to run a 32bit application of course all libraries it depends on must also be installed as 32bit. This is why on a typical x86-64 system, important libraries are installed twice: Once in 64bit, once in 32bit.
Thank you for your answer!
Regards,
Stefan
Offline
Thank you all for your answer, I am downloading Arch Linux right now to evaluate it in a virtual machine first.
Two other questions have come to my mind, though. ![]()
1) Do arch packages have cryptographic signatures to verify that nobody has e. g. hacked a mirror and messed with them?
2) Are there tools to remove unneeded dependencies? For example, if I install application A that pulls dependencies C and D and now decide to remove A again, how can I automatically get rid of C and D? Or asked differently: Is there an arch equivalent for "emerge -av depclean" on Gentoo or "debfoster" on Debian?
Thanks again!
Regards,
Stefan
Offline
1) I don't know
2) pacman -Rs <package A> should do that
Offline
1) Do arch packages have cryptographic signatures to verify that nobody has e. g. hacked a mirror and messed with them?
No - it's something that's been talked about, but not yet put into any kind of implementation.
2) Are there tools to remove unneeded dependencies? For example, if I install application A that pulls dependencies C and D and now decide to remove A again, how can I automatically get rid of C and D? Or asked differently: Is there an arch equivalent for "emerge -av depclean" on Gentoo or "debfoster" on Debian?
Pacman will handle this quite nicely - when you remove package A, run the command
pacman -Rc A(or maybe -Rs. I keep forgetting which of the two does which - in any case the functionality is there) and that will recursively remove dependencies that A installed, provided no other package on your system depends on them.
Last edited by Cerebral (2007-07-18 18:43:33)
Offline
pacman -Rs
![]()
Offline
Pages: 1