FS#3726 - Dummy X lib packages in current installed during xorg 7 upgrade

Attached to Project: Arch Linux
Opened by Tom Killian (tomk) - Saturday, 07 January 2006, 19:05 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture not specified
Severity High
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

During upgrade to xorg 7, the following dummy packages from the current repo were installed:

libx11 0.9.9-1
libsm 0.9.9-1
lixt 0.9.9-1

The testing repo holds the correct 1.0.0-1 version of all of them, but because testing is at the end of my pacman.conf list, the dummys were found first.

X was unable to start without these missing libraries.
This task depends upon

Closed by  Judd Vinet (judd)
Saturday, 07 January 2006, 23:48 GMT
Reason for closing:  Not a bug
Comment by Judd Vinet (judd) - Saturday, 07 January 2006, 21:35 GMT
The intended usage of Testing is to have it as the first repo in pacman.conf. Otherwise you will continually run into this Current-supercedes-Testing problem. You can always override the packages manually though.

# pacman -S testing/libx11 testing/libsm testing/libxt
Comment by Tom Killian (tomk) - Saturday, 07 January 2006, 21:44 GMT
Thanks Judd. That explains it alright, but it is also contrary to advice (not from you, admittedly) all over the forums and mailing list that it's a good idea to put Testing last, so you can choose which Testing packages you want to install. I have already overridden this using testing/foo as you suggest. I suppose my expectation was that all components of xorg 7 would be coming from testing, so there wouldn't be any repo clashes.
Comment by Judd Vinet (judd) - Saturday, 07 January 2006, 21:56 GMT
Well, I had a choice when implementing the --sync stuff. When looking for matching packages, pacman could take preference either way -- it could pick the latest version (ie, highest) from all repos, or it could pick the first one it finds in the repo list.

I stuck with the latter to try to minimize "cross-repo pollination". The advantage is that the user gets better control over repository preference, as pacman will respect the order you decree in pacman.conf. The disadvantage is the same, as you've found out. :)

I've thought about adding some configurability to some of pacman's algorithms, so power users could tweak the behaviour. But there's a lot going on with pacman3 lately, and it's just not the right time to start fiddling with things like that.
Comment by Tom Killian (tomk) - Saturday, 07 January 2006, 23:23 GMT
I think the way it works now is the right way - up to this, I've never had a problem, but this is an exceptional situation anyway. If there's tweakability somewhere down the road, all well and good, but definitely just nice to have.

Thanks again for your interest, and please close this non-bug.
Comment by Jan de Groot (JGC) - Saturday, 07 January 2006, 23:26 GMT
I think I could add some versioned dependencies on libraries in testing that depend on the dummies to solve the problem. Still doesn't solve the case where the user uses repositories in a way they shouldn't use :P
Comment by Tom Killian (tomk) - Saturday, 07 January 2006, 23:39 GMT
OK, OK - I get the message. I'm a bad, bad person. I'll never do anything like this again, I promise.

Happy now? :D

Loading...