Misfit138 wrote:So as stated above, just do
pacman -Syu <package>
instead.
Once pacman-3.4 is released... that commit is only in git at the moment.
What do you mean by "that commit is only in git"? We can already do pacman -Syu <package>, so I'm missing something
]]>Misfit138 wrote:So as stated above, just do
pacman -Syu <package>
instead.
Once pacman-3.4 is released... that commit is only in git at the moment.
Ah! Thumb-up.
]]>So as stated above, just do
pacman -Syu <package>
instead.
Once pacman-3.4 is released... that commit is only in git at the moment.
]]>$ pacman -Syu
$ pacman -S pkg
and
$ pacman -Sy pkg
If the pkg in question depends on newer packages. -Sy gets the latest package database and, I think, makes perfect sense. The -Su does a full update of installed packages. But I assume -S pkg will update any installed dependent packages if those require updating. So if pkg requires pkglib v2.1 and you have pkglib v2.0, "pacman -Sy pkg" it will update pkglib v2.0 to v2.1 as well. And thus, all your installed packages that depend on pkglib v2.0 will now break. So you're safer doing a "pacman -Syu" in the hopes that it will update all those packages that rely on pkglib v2.0 to now use pkglib v2.1 . Probably one reason to not do "pacman -Syu" too often so that packages can get caught up to upgraded dependencies.
But not updating the package database will use out of date information, which is never a good idea. As Allan says, Arch and its "rolling release" cycle assumes you are competent enough to figure out out these (hopefully) temporary update problems.
Nevermind - I didn't notice the 2nd page of replies in this thread so all the above has already been hashed out. Sorry 'bout that.
]]>I might have missed it, but I don't think that this have been linked earlier: http://bugs.archlinux.org/task/15581
Comment by Dan McGee (toofishes) - Monday, 07 September 2009, 10:58 GMT-5
So the long and short of this: "-Syu pkgname" would generate a sysupgrade transaction that also has one (or more) additional packages in the target list? This seems pretty sane, and no reason not to support it, right?
Comment by Xavier (shining) - Monday, 07 September 2009, 11:04 GMT-5
Fine then, it took me less than 5 min to write a patch, which I think I even dropped.
I will just do it again, updating help/doc and stuff.
Closed by Xavier (shining)
Saturday, 12 September 2009, 06:55 GMT-5
Reason for closing: Implemented
So as stated above, just do
pacman -Syu <package>
instead.
]]>..Do the repos standardly keep around more than the latest version of a package?...
No, and I perceive this is where the mismatch would stem from, i.e. an older version in your local package cache vs. the newer (and only) version available in the remote server.
... the issue is you may pull, now and everytime you'll install some new package without a prior system update, some package that have been built against libs that are not installed on your machine.
^ The crux of the issue.
So, we may conclude that pacman -Sy is not generally recommended unless you can be confident that there is little chance that your local cache is heavily out of synch with the remote server, since pacman could potentially pull in package(s) which have been built against newer versions of libraries, along with the newer libraries as dependencies. Since the installed packages on the local machine are built against the older version, a system-wide breakage of multiple packages could occur.
Bottom line, to make it a no-brainer, don't generally refresh without upgrading and just do
pacman -Syu <package>
unless you know exactly what you are doing, of course.
Correct me if I'm wrong, though.
* there's an extra database refresh, so it take a bit longer
* if foo had been updated since your last database refresh, `pacman -S foo` will fail but `pacman -Sy foo` will install it. Installing might not be the best choice, though, because foo may depend on a newer version of some library you already have installed. `pacman -S foo` won't work in this case, but it's better to see that it doesn't work, and that you need to do a `pacman -Syu` before proceeding.
Is that about right?
]]>shrimphead wrote:Surely this will be fixed with a pacman -Syu though.
Yes.... but you might have to boot into a rescue disk to do that for some of the more essential libraries.
A fair point, well made!
]]>Surely this will be fixed with a pacman -Syu though.
Yes.... but you might have to boot into a rescue disk to do that for some of the more essential libraries.
]]>Say for example you have libjpeg7 installed on your system and at one time something comes in the repo that requires libjpeg8. You pacman -Sy this package and libjpeg8 is installed and libjpeg7 is uninstalled because the two conflict.
Therefore all your applications that need libjpeg7 are probably broken.
Surely this will be fixed with a pacman -Syu though.
I would normally be a bit more on the ball when checking what a pacman -Sy was pulling in. So, a simple check to see what libraries will be updated would avoid most of the problems right?
From what I gather there is no real disadvantage to using -Sy as long as you are confident in your system and what is installed?
]]>Cdh wrote:Profjim wrote:(Is that really true? `pacman -Sy foo` might upgrade some dependencies, it won't restrict itself to only pulling in packages I don't yet have installed? Or have I misidentified what it is bad that `pacman -Sy foo` might do?)
Say for example you have libjpeg7 installed on your system and at one time something comes in the repo that requires libjpeg8. You pacman -Sy this package and libjpeg8 is installed and libjpeg7 is uninstalled because the two conflict.
Therefore all your applications that need libjpeg7 are probably broken.Really? `pacman -Sy foo` will upgrade any dependencies of foo available to be upgraded? Whereas `pacman -S foo` won't? I don't have contrary evidence, I'm just surprised. I didn't expect this behavior and haven't ever noticed it happening. Of course, I don't think I often do 'pacman -Sy foo' anyway.
most of the time it won't pull deps. it will only if the package has versioned deps, which should be quite rare.
edit2: nvm
Cdh wrote:Profjim wrote:However, if my local cache of the repo metadata is out of date, say locally I think the latest version of foo (or of a lib foo depends on that I don't have installed) is 1.0, but remotely the latest version is 2.0, what will happen when I do `pacman -S foo`? I'll get version 2.0? The install will fail? I don't think I'll get version 1.0, will I?
You will get the last version your local pacman knows. It's a bit safer because:
* Like the above scenario pacman does not know about the new package which depends on libjpeg8. It tries to install the one he knows
* If the old package does not exist anymore in the repos you get a clear error message and nothing is broken.Do the repos standardly keep around more than the latest version of a package? If so, is there any rule about how far back they preserve? N version bumps? Version bumps from the last N days?
only few repos keep older versions. IIRC there's only one actually.
]]>