pacman -Sy <somepkg>: Why is this bad?

sand_man · 2010-01-23 06:03:47

Profjim wrote:

sand_man wrote:
Another problem with doing pacman -Sy pkg. Even if that doesn't break anything, if you then go and install other packages without upgrading the system, you might (or might not) eventually break something. So you are always just better off to pacman -Syu if you are after the latest version of a package.
Yes, but I think this thread is about how best to install new packages, not about doing piecemeal upgrades.

I understand but if you want the newest version then you should always upgrade the system first.
I mean, you don't always have to but it is the safest option. I never had a problem with libjpeg or readline updates because I always make sure my system is up to date.

Last edited by sand_man (2010-01-23 06:04:50)

bangkok_manouel · 2010-01-23 07:11:54

Profjim wrote:

Let me review and see if I've got this right. If I want to install a new package foo, the best approach is:
pacman -Syu
pacman -S foo
The following, alternative approach is dangerous because it might update some of the libraries I already have installed that some of my other packages use, without upgrading those other packages:
pacman -Sy foo
(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?)

it may pull some dependencies if the version of the deps is specified (e.g. libjpeg>=8) but that's not the main problem. 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.

Profjim wrote:

This is allegedly somewhat better:
pacman -S foo
though not as good as the first option. One reason it's better is that it doesn't waste time synching. But it's also allegedly safer. (Why exactly?) 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?

it's safer as you are sure what you're gonna pull is based on "the same repo snapshot" as your current system. as you mentioned, if you've been waiting too long, you'll get a nice "file not found"...

edit: w00t ! 1,000th post ! can I be mod for a day ?

Last edited by bangkok_manouel (2010-01-23 07:14:07)

Cdh · 2010-01-23 08:35:39

Profjim wrote:

Let me review and see if I've got this right. If I want to install a new package foo, the best approach is:
pacman -Syu
pacman -S foo

Yes!

Profjim wrote:

The following, alternative approach is dangerous because it might update some of the libraries I already have installed that some of my other packages use, without upgrading those other packages:
pacman -Sy foo
(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.

Profjim wrote:

This is allegedly somewhat better:
pacman -S foo
though not as good as the first option. One reason it's better is that it doesn't waste time synching. But it's also allegedly safer. (Why exactly?) 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.

Profjim · 2010-01-23 11:48:03

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.

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?

bangkok_manouel · 2010-01-23 11:56:22

Profjim wrote:

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

Profjim wrote:

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.

Last edited by bangkok_manouel (2010-01-23 12:08:56)

shrimphead · 2010-01-23 12:24:06

Cdh wrote:

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?

Allan · 2010-01-23 12:26:20

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.

shrimphead · 2010-01-23 13:07:35

Allan wrote:

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!

Profjim · 2010-01-23 13:52:43

Going by what bangkok_manouel says, but setting the case of packages with versioned dependencies aside, I'm inferring that these are the ways in which `pacman -Sy foo` is potentially worse than `pacman -S foo`:

* 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?

Allan · 2010-01-23 14:05:28

yes

Misfit138 · 2010-01-23 14:52:19

Profjim wrote:

..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.

bangkok_manouel wrote:

... 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.

Mr.Elendig · 2010-01-24 10:30:00

I might have missed it, but I don't think that this have been linked earlier: http://bugs.archlinux.org/task/15581

Misfit138 · 2010-01-24 14:55:40

Mr.Elendig wrote:

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.

jdarnold · 2010-01-24 14:59:58

Jumping in here as a relative Arch newbie, just to make sure I understand things too. I don't believe either of the following two methods help at all in avoiding package update problems:

$ 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.

Last edited by jdarnold (2010-01-24 15:02:35)

Allan · 2010-01-24 15:01:39

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.

Misfit138 · 2010-01-24 15:14:04

Allan wrote:

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.

Cows · 2010-01-26 07:45:23

Allan wrote:

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

Allan · 2010-01-26 08:03:07

Yes. Try it and note that <package> does not actually get installed...

Cows · 2010-01-26 21:07:28

Oh yea, I noticed that as well. I thought it was awkward when I tried that and it didn't work a few days ago. I don't know but personally, reporting bugs is like a pain for me. It's like go here, no go over here, oh wait a minute... go over here.

Arch Linux

#26 2010-01-23 06:03:47

Re: pacman -Sy <somepkg>: Why is this bad?

#27 2010-01-23 07:11:54

Re: pacman -Sy <somepkg>: Why is this bad?

#28 2010-01-23 08:35:39

Re: pacman -Sy <somepkg>: Why is this bad?

#29 2010-01-23 11:48:03

Re: pacman -Sy <somepkg>: Why is this bad?

#30 2010-01-23 11:56:22

Re: pacman -Sy <somepkg>: Why is this bad?

#31 2010-01-23 12:24:06

Re: pacman -Sy <somepkg>: Why is this bad?

#32 2010-01-23 12:26:20

Re: pacman -Sy <somepkg>: Why is this bad?

#33 2010-01-23 13:07:35

Re: pacman -Sy <somepkg>: Why is this bad?

#34 2010-01-23 13:52:43

Re: pacman -Sy <somepkg>: Why is this bad?

#35 2010-01-23 14:05:28

Re: pacman -Sy <somepkg>: Why is this bad?

#36 2010-01-23 14:52:19

Re: pacman -Sy <somepkg>: Why is this bad?

#37 2010-01-24 10:30:00

Re: pacman -Sy <somepkg>: Why is this bad?

#38 2010-01-24 14:55:40

Re: pacman -Sy <somepkg>: Why is this bad?

#39 2010-01-24 14:59:58

Re: pacman -Sy <somepkg>: Why is this bad?

#40 2010-01-24 15:01:39

Re: pacman -Sy <somepkg>: Why is this bad?

#41 2010-01-24 15:14:04

Re: pacman -Sy <somepkg>: Why is this bad?

#42 2010-01-26 07:45:23

Re: pacman -Sy <somepkg>: Why is this bad?

#43 2010-01-26 08:03:07

Re: pacman -Sy <somepkg>: Why is this bad?

#44 2010-01-26 21:07:28

Re: pacman -Sy <somepkg>: Why is this bad?

Board footer