You are not logged in.
I changed video card in my system and needed a new xf86-video-driver
#pacman -S xf86-video-s3virgebut that didn't work because it couldn't find any packages (at all), only after I updated pacman and it's database I was able to download it but then it says that package was incompatible with initscripts and it removed it, then the system was unbootable, I booted a rescue cd, connected to the network and redownloaded initscripts, the initscripts came back and worked but this time at boot I get an error with udevd, something about GLIBC_2.9 not found in /lib/libc.
which becomes obvious to me that I can't update libc, so I am going to have to downdate the udevd - but the problem here is I have no idea where to download the old binary release compatible with my system, arch linux 2008.6 is no longer available in the download section.
Offline
http://wiki.archlinux.org/index.php/Dow … g_Packages
It sounds like you ran
pacman -Sywithout upgrading the whole system. That will lead to breakage. Did you try simply running
pacman -Syufrom a rescue cd?
Offline
I always have to update ALL the packages every time I need a something like a different (not even updated) video driver ?
if it is necessary why wasn't pacman designed to do that default all the time anyway ?
ok im gonna try your idea first seems like you recommend it
on the other hand, -Syu will probably also update libc, which means all the packages I compiled myself will no longer function
is there a package repository that never changes ?
Last edited by manoa (2010-06-12 21:18:56)
Offline
Since Arch rolls there's really no official repository with old packages. The idea about forcing an -Syu on a user every time would exclude other switches and hence limit user control.
Is there a particular reason for why you have kept some parts of your system not updated? I you have a special reason you could try to single out a group of packages that depends on each other and keep those old packages in a local repository. Depending on what packages we're talking about it could work for a limited amount of time, but eventually I suppose it would lead to a point where you have to decide whether to stop upgrading or bite the bullet and get those new packages to work the way you want them.
As I see it Arch isn't a good choice of distro if you don't roll together with it.
Offline
Is there a particular reason for why you have kept some parts of your system not updated?
one of the fist problems I have noticed when using updating, is unpredictable behaviour - dhcpcd 4 and 3 are one example (which I guess does not require introduction), an another example is that new version of xorg-server no longer respects the keyboard rate/delay switches in the device section, and those two experiences I discovered are only when I had to update for the xf86-video-s3virge, I can't imagine what a mess I would have to clean up if I had used updating. updating is unreliable (although given the current state of xorg's development it might actually be within a resonable limit, it could have been far worse), don't get me wrong, I do trust the devs for building their packages, and in some cases I do update packages (like kernel, but it is manually configured and compiled) - but never everything and most certainly not all at once (and when I do, it is usually with -nodeps first and only after reading changelogs). I can't take the risk that something (not due to flaws or such) is not functioning as it is expected, which may be due to the obvious target audience of the distribution (clients, modern hardware etc). and we're not talking about parts here, I never globally updated since the original distribution release 2008.6.
I have done alot of -Rs and -Rsc and with and without -nodeps, despite arch best efforts to remain customizable it apparently wasn't enough for me eventually otherwise I wouldn't have to do that nor compile over 30 programs manually, I am also not using "modern defaults" like gnome/kde, instead it is fluxbox with gtk+1.2.10 and also lesstif stuff, in part because they are faster "platforms" than any other modern graphics backend, but also because the hardware is a dual pentium 3 500 mhz, another example is I don't use a LCD monitor nor do I need any languages other than english on my system, so things like utf-8, iconv, text antialiasing etc.. are just in the way. I do use graphical interface for the server's management but it is strictly just that (not that I would use gtk2 on a client system either, but there hardware could allow it to be considered, but not on this one).
the problem is that many arch packages are built with assumptions that cause dependencies which have nothing to do with it's actual functionality - but once it was compiled in a certain way there is no other way to use it unless the dependencies are present, in those cases that it is possible - I use -Rsc and -nodeps then build the package myself properly.
As I see it Arch isn't a good choice of distro if you don't roll together with it.
tell me about it, it's too bad that this is something I have had to figure out recently, I had similar considerations earlier but the consequences were never as grave as this before so I didn't bother paying too much attention.
p.s. if I ever get the motivation to "bite the bullet", it wouldn't be to make new packages to work the way I want them all the time, it would be used to build LFS, since it seems that is the only thing worth biting for. although there was a time when things were different like turbo/slack/mandRAKE/RH7.3 but many of those either changed too much in recent years or just dont exist, maybe debian is the real deal....sometimes it seems I am spending more effort into finding and properly building a distribution than I would have if I had "bit the bullet" (although, unfortunately that process too has problems of it's own, such as the need to have intimate understanding of each package's configuration options to be properly executed (copy paste LFS doesn't get you nowhere), and things like patching of my own of the build scripts as well as proper compilation options that sometimes take you as far as manually editiing Makefile.in. I was hoping to use arch to collect information about how I want to build my packages, it is successfull, to a rather high extent, but the mission is not complete (there are still packages that I am using precompiled by arch. but it also has limits such as not being able to experiment with building libc/binutils and other lower level linux software).
Last edited by manoa (2010-06-13 03:06:58)
Offline
As you understand, and also imply, not everyone expect the same as you do, and hence shaping Arch in your liking would probably disappoint the majority of its user base. There's a reason Arch became what it is. Arch isn't patched to avoid being recent but still being secured by new releases of software it uses.
If you like the system structure of Arch, but want something more conservative, and since you obviously have the knowledge, you could choose to support the Arch Server project: http://www.archserver.org/.
Offline
-Syu did it, inotify support was missing from my kernel so I had to download arch kernel as well after another reboot.
lots of packages are broken because they depend on older versions which are no longer available - but far less than expected, the important thing is the system as whole now works well, thx. I guess I will have to spend some time with it, but it should be fine eventually.
Offline