You are not logged in.
Udev 145-1 package has set conflict with initscripts<2009.07 package. During system upgrade initscripts have been removed from the system. (I had older package than 2009.07). Maybe initscripts should be moved to "depends" section?
Offline
If you were getting this conflict your system was out of date since the newest version of initscripts is 2009.08. Make sure everything is updated with pacman -Syu, and you shouldn't try rebooting without the current initscripts
Offline
Problem is, that upgrade doesn't upgrades initscripts. If someone have old initscripts and old udev packages then pacman -Su removes initscripts (because it conflicts witch udev), not upgrades it. I consider it as a mistake.
Offline
Try changing your mirror and using "pacman -Syyu".
Offline
I am sorry, but how is it going to help? Until there is conflict in package, old initscripts will be removed not upgraded.
Offline
what?
> pacman -Si initscripts
Repository : core
Name : initscripts
Version : 2009.08-1Update, and udev will not conflict with the current initscripts. They need to be updated at the same time as the new udev does not work with the old initscripts (hence the conflict).
A full update should fix you problem. If not, change mirror like I suggested.
Offline
I have solved that problem by upgrading initscripts by hand. True.
I've posted this topic, because everyone, who has old initscripts and old udev will encounter this same problem after pacman -Su. Because:
pacman -Si udev
Repozytorium : core
Nazwa : udev
Wersja : 145-1
URL : http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
Licencja : GPL
Grupy : base
Dostarcza : Żadnych
Zależy od : glibc coreutils util-linux libusb glib2
Opcjonalne zależności: Żadnych
Conflicts : initscripts<2009.07
Zastępuje : devfsd
Ilość danych do pobrania: 333,24 K
Rozmiar po instalacji : 1488,00 K
Pakujący : Tobias Powalowski <tpowa@archlinux.org>
Architektura : i686
Data budowy : nie, 2 sie 2009, 18:27:50
Suma MD5 : 854243e8ba9513192a8adee9feeb2bf1
Opis : The userspace dev tools (udev)I have polish version of pacman. Pacman _will_remove_ initscripts after pacman -Su. Adding initscripts>=2009.08-1 to depends would solve problem, i think. Changing repo won't help, as far initscript figures in conflicts list.
Check http://bbs.archlinux.org/viewtopic.php? … 38#p614338 for example. It's coming ![]()
Last edited by kalavan (2009-09-06 13:45:41)
Offline
pacman is smart enough to figure out that when you are upgrading the whole system then the new initscripts does not conflict with the new udev. People only run into this problem when they use "pacman -Sy" followed by "pacman -S <pkg>" where <pkg> requires the new udev. Never use "pacman -Sy", only "pacman -Syu".
Edit: also note that you have to confirm the removal of initscripts. Surely that sounds like an important package to keep...
Offline
Well, maybe you are right, but it sounds bad, that i have to upgrade whole system to install a single package. Anyway, thanks for your time, Allan ![]()
Offline
Well, maybe you are right, but it sounds bad, that i have to upgrade whole system to install a single package. Anyway, thanks for your time, Allan
You don't have to upgrade the whole system to install a single package. But if you are going to install a single package, don't parse the -y option. Only parse the -y option if you are going to upgrade the whole system!!
![]()
Offline
Next version major version of pacman changes the default answer to no with conflict resolving.
Moreover, versioned conflicts will be printed in parentheses to inform the user about the fact that only the old version is bad, it should be upgraded (and not removed!). Example: "udev and initscripts are in conflict (initscripts<2009.07), remove initscripts? [y/N]"
Offline
This same thing just happened to me, and I also consider it a serious mistake on someone's part.
Removing initscripts will break the system, period. Pacman should not allow it to be removed without some serious --force --I-really-mean-it-and-want-to-make-my-system-unbootable command line flags, ever.
And this repeated advice for people to just "pacman -Syu and this won't happen" is not constructive.
Touching potentially tens or hundreds of packages at once is always a bad idea, especially on important production systems and servers. It often breaks things and requires hours to fix. Asking people to do that is not good or valid advice, so some effort should be made to prevent individual package upgrades from breaking things as important as initscripts, bash, agetty (did anyone else with a custom inittab miss the tty name change a while ago and find they couldn't log in?), and so on.
Offline
There are so many things wrong with that post:
1) Arch only supports the current packages in our repos. If you want to only upgrade part of your system, then it contains software that we do not support and you are on your own. Thus "pacman -Syu" is the only supported way to upgrade.
2) Important production systems and servers obviously require a test system on which any upgrade should be tested first. If not, you really want to be using Debian, CentOS or some other "stable" distro. Even then, you are stupid if you upgrade without testing.
3) The initscripts change was announced on the frontpage, /etc/inittab was automatically changed from using vc/* to tty*. Not much else could be done apart from us coming to update your system for you...
Offline
Not much else could be done apart from us coming to update your system for you...
Well, now you know what to do ! ![]()
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
1) Arch only supports the current packages in our repos. If you want to only upgrade part of your system, then it contains software that we do not support and you are on your own. Thus "pacman -Syu" is the only supported way to upgrade.
Well, what I'm trying to avoid is having really minor package installations break something major. For instance, I was trying to update my web browser (opera), which needed a qt update, which need a gstreamer update, which needed a udev update, which auto-uninstalled initscripts, which made my laptop unbootable for a little while.
That's like the time I was trying to debug something on an older server at work (which was running Gentoo), tried to do a DNS lookup from that machine's point of view, found that it didn't have dig or nslookup, tried to emerge it, and it broke the kernel.
There has to be a way to make stuff like that less likely to happen, without requiring a massive download to update some 5 KB command line utility or some userspace thing like a web browser.
Another situation that's really difficult to avoid with a full system update is when you *know* there's a newer package with lots and lots of new bugs in it that won't be fixed for months. I'm thinking of KDE 4 here. Or when a package has been dropped from the repos and updating certain things will break it and require custom compiling to get it back (e.g. gnucash a while ago; that's fixed now).
Offline
There has to be a way to make stuff like that less likely to happen, without requiring a massive download to update some 5 KB command line utility or some userspace thing like a web browser.
Of course there is a way. NOT USING a rolling release distrib !
I will never understand why so many users fail to understand this so obvious aspect.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
thetrivialstuff wrote:There has to be a way to make stuff like that less likely to happen, without requiring a massive download to update some 5 KB command line utility or some userspace thing like a web browser.
Of course there is a way. NOT USING a rolling release distrib !
I will never understand why so many users fail to understand this so obvious aspect.
I suppose you've got me there... But Arch does everything else I want so well! It really is my favourite of all the distributions I've tried, and I *do* appreciate how easy the rolling release thing makes major upgrades -- when I want to do that, that is. I guess I want the best of both worlds somehow. Has anyone looked into ways of snapshotting the pacman repositories or some such?
Offline
I suppose you've got me there... But Arch does everything else I want so well! It really is my favourite of all the distributions I've tried, and I *do* appreciate how easy the rolling release thing makes major upgrades -- when I want to do that, that is. I guess I want the best of both worlds somehow. Has anyone looked into ways of snapshotting the pacman repositories or some such?
This would require a lot of effort and a lot of manpower. But it seems there would also be potentially many users interested.
I guess it would require a few very motivated people to lead the project and get the required resources.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline