pacman -Sy is a Bad Idea

[postmodern]

pacman -Sy is a Bad Idea

[mbj]

Yeah I think pacman -S list of dependencies is enough. If a dependency is missing / uninstallable arch user can decide for himself to update the index. This would fit my workflow.

[postmodern]

The problem with leaving the index not-updated, is we might install old/buggy versions of packages. Updating the index shouldn't break your system, until you update all packages? IMHO, if -Sy is dangerous, the Arch developers should remove the -y option.

[pbrisbin]

I don't think you understand the problem @postmodern. I'll try to summarize from the linked thread and other conversations had numerous times in #archlinux.

Updating the index (-Sy) and then installing a package (-S foo) without updating the whole system can lead to a state of old and new software on the system at the same time (new foo and old everything else).

This mixed state is officially "unsupported" in Arch (being the rolling release distro that it is) and if soname bumps happen to be occurring at the time you get into this state, it can very severely break your system.

Sy will not be removed as it does exactly as is advertised and can be very useful when you know what it does and how it works -- this is the opinion of the Arch devs (and mine, though that's less important).

In general, Arch being rolling release and targeted at competent users means it's far better to assume they manage their own index correctly and simply doing pacman -S dep will work as you expect than to do an automated -Sy which is strongly advised against by the distro maintainers.

If -S foo causes breakage because the user's index is out of date, that's their own fault. If ruby-install's -Sy causes breakage, that's yours. Regardless of how likely either are (and I assert the latter is more likely than the former) the choice should be clear.

Again, -Sy is not itself bad, just when it's done in an automated way.

[postmodern]

Interesting. I expected the new dependencies of the new package to force other packages to be updated automatically. I guess that's a design limitation of pacman?

OK, I will remove the -Sy.

[pbrisbin]

Thanks for making this fix. I wouldn't call it a design limitation, just a design decision.

Perhaps an example:

• A user has firefox 3.0 and gimp 6.1 installed, both of which depend on libpng>=1.0
• An update comes out for libpng to version 1.2
• Arch maintainers release libpng 1.2, firefox 3.0-2 and gimp 6.1-2 which now depend on libpng>=1.2
• An update comes out for firefox to version 3.1
• Arch maintainers release firefox 3.1 which depends on libpng>=1.2
• Our user (incorrectly) says pacman -Sy firefox hoping to get this new version
• pacman (correctly) installs firefox 3.1 and libpng 1.2

There's nothing here to tell pacman to update gimp since libpng 1.2 is >= 1.0 which is gimp's dependency.

However, our user's gimp is linked directly to /usr/lib/libpng.so.1.0 and is now broken. Sadface.

There are a few ways to avoid this situation:

1. The user doesn't use Arch or any rolling release distro, they get new firefox in a few months.
2. The user does pacman -Syu to update the index, the system, and get the new version of firefox (along with libpng and gimp).
3. The Arch maintainers set a hard constraint on firefox and gimp to libpng==1.0, -Sy firefox would produce an error for unresolvable dependencies. This error would indicate to them they need to update gimp too.

Arch as a group has chosen the second option, and simply instructed users to not use -Sy (without u) unless they know what they're doing. For example, -Sy firefox would be fine and useful if a) the user did not want to update their system but wanted newer firefox and b) the user knew firefox wouldn't bring in any shared object library updates breaking other dependent packages or c) the user manually rebuilt those packages against the new library.

The third option might look attractive but it creates a huge headache for the repo maintainers due to the hard constraints making it difficult to move groups of inter-dependent packages from unstable -> testing -> core repositories. It also wouldn't even solve the specific use case for ruby-install since it would just error; having pacman -Sy firefox also install gimp would be far too auto-magical for us Arch users.

And now you know more than you probably ever wanted about Arch Linux repository management.

[mbj]

@pbrisbin Thx for that description, I wasnt able to write my thoughts down that consistent!

[postmodern]

Another thing I thought of, is that ruby-install only installs missing pacman packages. So we shouldn't ever install a new version of openssl. https://github.com/postmodern/ruby-install/blob/master/share/ruby-install/ruby-install.sh#L107-L111

[pbrisbin]

Well, the fact that you'll only install new and not update doesn't change things. The scenario above would've still broken the user's gimp had step 6 been a fresh install of firefox.