arch upgrade with pacman -Su

doru001 · 2013-01-27 13:35:27

Just to be sure, pacman -Sy is the upgrade instruction in arch and it can not be undone? Before that, I am using the old package list and I install and upgrade packages (pacman -S) within that list. After that, I am using the new package list and I work within it. Is this correct?

graysky · 2013-01-27 13:47:16

You can always downgrade a package if you need to via `pacman -U xxx`. You should update your mirrorlist via `pacman -Syy` if you changed mirrors. If not, a simple `pacman -Syu` will sync and update your system to the mirror.

doru001 · 2013-01-27 14:17:10

graysky wrote:

You can always downgrade a package if you need to via `pacman -U xxx`. You should update your mirrorlist via `pacman -Syy` if you changed mirrors. If not, a simple `pacman -Syu` will sync and update your system to the mirror.

I should use `pacman -S xxx=version`, I suppose. Anyway, the big question is about `pacman -Sy`. It can not be undone, right? And after it pacman uses a new package list, which defines a new "distribution".

Last edited by doru001 (2013-01-27 14:40:10)

graysky · 2013-01-27 14:43:19

No, it can be undone by manually downgrading packages. Arch is a rolling release; there are no discrete versions.

xxx = filename

1) Look on the wiki for the ARM (Arch Rollback Machine)
2) Look in your pacman cache dir if you save old files

doru001 · 2013-01-27 15:20:25

graysky wrote:

No, it can be undone by manually downgrading packages. Arch is a rolling release; there are no discrete versions.
xxx = filename
1) Look on the wiki for the ARM (Arch Rollback Machine)
2) Look in your pacman cache dir if you save old files

Well, of course there are versions, they are printed with `pacman -Q` and they can be specified with `=`, according to the pacman manual.

It is good to know that there is Arch Rollback Machine, however this looks pretty complicated and it is not even on archlinux.org. The idea is that this is how it works: `pacman -Sy` will update the package list and then you are done, all new pacman operations use the new list. Hard to revert.

Trilby · 2013-01-27 15:21:30

My advice is to *never* do a `pacman -Sy` - only do `pacman -Syu`. The first one is asking for trouble.

There aren't separate package lists. Whenever you install a package from the repositories, you are getting the most up to date version in the repo. If your local database is old, the installation of a new package will work if that package hasn't changed, but if it has the package will not be found on the repo until you sync your database.

If you sync your database (`pacman -Sy`) then install something new (`pacman -S <packages>`) you will have done a partial upgrade and there is a good chance something will break. So never do -Sy, only -Syu.

cfr · 2013-01-27 15:51:16

doru001 wrote:

graysky wrote:
No, it can be undone by manually downgrading packages. Arch is a rolling release; there are no discrete versions.
xxx = filename
1) Look on the wiki for the ARM (Arch Rollback Machine)
2) Look in your pacman cache dir if you save old files
Well, of course there are versions, they are printed with `pacman -Q` and they can be specified with `=`, according to the pacman manual.

But there are not "old" and "new" distributions. There is no such thing as a version of Arch or a versioned distribution. There's just one distribution which is rolling release.

doru001 · 2013-01-27 16:13:49

Trilby and cfr, but especially Trilby: thank you very much for finally making it clear to me what is going on. So if the package has been updated in the repository and I do not update my package list then the package becomes unavailable to me. `pacman -Ss package-name` will not find it at all, right?

The packages in the repository are not tested before updating. When a stable release becomes available upstream, then they are updated on arch, right? So I have to search bbs before I do `pacman -Syu`, to ensure that `pacman -Syu` will not break my system. I wonder, however, if some testing is made in order to prevent the breaking of the entire arch repository when one package is updated.

Also, I should never do `pacman -Sy` because if after that I do `pacman -S some-package` I may receive a version which is newer than that required by old packages which depend on it and this might again break everything on my system. Right?

Last edited by doru001 (2013-01-27 16:17:53)

Trilby · 2013-01-27 17:00:02

To respond in parts, 1) I'm not sure if pacman -Ss would find it or not, but it could certainly fail to download it when you attempted and -S.

2) Packages are tested. That is what the [testing] repo is for. While arch is "bleeding edge" and one should be ok with occasional "breakage", arch is - for the most part - stable with updates. Pacman -Syu does *not*, as a rule, break anything ... but there are some exceptions to this rule. Frequent updates minimize such breakage. I update daily, so as minor ripples come down stream I can deal with them painlessly. Others have waited over a year to update, and all those ripples have summed to a tidal wave that might well destroy their home (ok, actualy the metaphor breaks as /home will be fine, but they may have to reinstall /).

2 additional info) It is recommended to check the front page news before updating (-Syu). But I don't feel the need to. As above, I update daily, so any issues are very minor (and also very rare). But if I see anything out of the ordinary, I stop what I'm doing, and I check the front page news.

3) Exactly right -Sy, followed by an -S is the "partial upgrade" that users are warned to avoid. It could even be a reasonable feature for pacman to refuse a -Sy without a warning about why it should be -Syu, except that this would hinder those who know what they are doing from doing what they want. Pacman does exactly what it is told, and users should learn that some things are (generally) not a good thing to tell it.

doru001 · 2013-01-27 17:08:48

Trilby wrote:

To respond in parts, 1) I'm not sure if pacman -Ss would find it or not, but it could certainly fail to download it when you attempted and -S.

Anyway, I am safe from this mistake, I can not install a wrong version.

Trilby wrote:

2) Packages are tested. That is what the [testing] repo is for. While arch is "bleeding edge" and one should be ok with occasional "breakage", arch is - for the most part - stable with updates. Pacman -Syu does *not*, as a rule, break anything ... but there are some exceptions to this rule. Frequent updates minimize such breakage. I update daily, so as minor ripples come down stream I can deal with them painlessly. Others have waited over a year to update, and all those ripples have summed to a tidal wave that might well destroy their home (ok, actualy the metaphor breaks as /home will be fine, but they may have to reinstall /).

This is very important and I fail to understand: after reinstall, don't you end up with a system very close to what you had before? Or maybe you refer to some custom made configurations which you might have to change in order to make things work? This makes not too much sense, because basic configurations as I do don't usually break anything ...
Probably you refer to new utilities, like systemd, which need to be configured. So the system works after update, but not the way you wanted.

Trilby wrote:

2 additional info) It is recommended to check the front page news before updating (-Syu). But I don't feel the need to. As above, I update daily, so any issues are very minor (and also very rare). But if I see anything out of the ordinary, I stop what I'm doing, and I check the front page news.
3) Exactly right -Sy, followed by an -S is the "partial upgrade" that users are warned to avoid. It could even be a reasonable feature for pacman to refuse a -Sy without a warning about why it should be -Syu, except that this would hinder those who know what they are doing from doing what they want. Pacman does exactly what it is told, and users should learn that some things are (generally) not a good thing to tell it.

Last edited by doru001 (2013-01-27 17:17:41)

Trilby · 2013-01-27 17:21:57

doru001 wrote:

This is very important and I fail to understand: after reinstall, don't you end up with a system very close to what you had before?

I'm not sure if I'm reading the question right. Being forced to reinstall is very rare and highly unlikely. I only mention it as there is a currently active thread in which this may be the only option for a user who has not updated in over a year as the glibc update from last year paired with the recent filesystem update are hard to work through at the same time.

Even in this case though, if that user reinstalls, they will not get the same system they had before. They will have a system that not only lacks all their configuration and chosen packages, but also one that is completely up to date.

These are, however, extrememly rare "corner cases". One should never have to reinstall arch - just do regular updates.

doru001 · 2013-01-27 17:39:27

Trilby wrote:

I only mention it as there is a currently active thread in which this may be the only option for a user who has not updated in over a year as the glibc update from last year paired with the recent filesystem update are hard to work through at the same time.

Indeed this should be rare. I can't even understand how can this incompatibility appear. One runs the old system throughout the update process, and after reboot the updated system should be functional. So there should be no conflict between old and new packages.

By getting the same system I meant that when you do `pacman -Syu` you end up with a system close to the last monthly release which you would use in a reinstall, anyway. Only your custom config files may differ, a little bit.

Thank you for your answers, this is very interesting.

cfr · 2013-01-28 02:59:27

No, you will not necessarily get a system which differs from a reinstall only in your custom configs. First, you will sometimes need to adjust things manually which you would not need to do on a reinstall. This is why reading the output from pacman is vital. Second, certain things may be default if you reinstall but not if you update. For example, if you have an old system, upgrading won't result in your system using systemd for booting even though this would be the result if you reinstalled. To switch to systemd, you'd need to update and follow the wiki instructions. Similarly, the default network interface names differ on new installs versus updated installs. In the former case, the defaults are the "new" names. In the latter, the defaults are the "old" names.

doru001 · 2013-01-28 09:17:34

cfr wrote:

No, you will not necessarily get a system which differs from a reinstall only in your custom configs. First, you will sometimes need to adjust things manually which you would not need to do on a reinstall. This is why reading the output from pacman is vital. Second, certain things may be default if you reinstall but not if you update. For example, if you have an old system, upgrading won't result in your system using systemd for booting even though this would be the result if you reinstalled. To switch to systemd, you'd need to update and follow the wiki instructions. Similarly, the default network interface names differ on new installs versus updated installs. In the former case, the defaults are the "new" names. In the latter, the defaults are the "old" names.

Thank you, very good to know the info you posted. I'm sure that it saved me a lot of trouble.

Last edited by doru001 (2013-01-28 09:58:03)

doru001 · 2013-01-28 11:54:44

Trilby wrote:

Pacman -Syu does *not*, as a rule, break anything ... but there are some exceptions to this rule. Frequent updates minimize such breakage. I update daily, so as minor ripples come down stream I can deal with them painlessly. Others have waited over a year to update, and all those ripples have summed to a tidal wave that might well destroy their home (ok, actualy the metaphor breaks as /home will be fine, but they may have to reinstall /).

Once per month should do, because the install kit is renewed once per month, and one has to be able to update his system after install with little trouble. However, once every two weeks should be even better .

Mr.Elendig · 2013-01-28 13:06:11

doru001 wrote:

Just to be sure, pacman -Sy is the upgrade instruction in arch and it can not be undone? Before that, I am using the old package list and I install and upgrade packages (pacman -S) within that list. After that, I am using the new package list and I work within it. Is this correct?

1. man pacman (read the *whole* thing
2. https://bbs.archlinux.org/viewtopic.php … 61#p802661
3. What is it that you are _really_ trying to do?

Last edited by Mr.Elendig (2013-01-28 13:06:39)

doru001 · 2013-01-28 14:33:28

Mr.Elendig wrote:

doru001 wrote:
Just to be sure, pacman -Sy is the upgrade instruction in arch and it can not be undone? Before that, I am using the old package list and I install and upgrade packages (pacman -S) within that list. After that, I am using the new package list and I work within it. Is this correct?
1. man pacman (read the *whole* thing
2. https://bbs.archlinux.org/viewtopic.php … 61#p802661
3. What is it that you are _really_ trying to do?

1. this is against my deepest religious beliefs. Plus, I don't understand what it says.
2. I was curious how is the update handled. Curiosity saved the cat.
3. using arch safely

Trilby · 2013-01-28 15:17:16

I sense a joke in there (number 1) that I'm just not getting, but if you have an unwillingness to read man pages or an inability to figure out what they mean, then there is really no way you can acheive number 3.

doru001 · 2013-01-29 14:36:06

Trilby wrote:

I sense a joke in there (number 1) that I'm just not getting, but if you have an unwillingness to read man pages or an inability to figure out what they mean, then there is really no way you can acheive number 3.

resolving dependencies...
looking for inter-conflicts...

What is this message from `pacman -S package_name` really saying? We just established that pacman does not check for broken dependencies in the whole system before installs, and dependencies of the installed package are good from our current package list. There can be no conflicts, unless one has messed up the system.
The manual forgets to explain:

-S
-d, --nodeps
Skips dependency version checks. Package names are still checked. Normally, pacman
will always check a package’s dependency fields to ensure that all dependencies are
installed and there are no package conflicts in the system. Specify this option twice
to skip all dependency checks.

Here there is some "package conflicts" checking in the system. What are those about? Weren't they supposed to be explained under the "normal" behaviour chapter?

-S
--needed
Do not reinstall the targets that are already up to date.
--recursive
Recursively reinstall all dependencies of the targets. This forces upgrades or
reinstalls of all dependencies without requiring explicit version requirements. This
is most useful in combination with the --needed flag, which will induce a deep
dependency upgrade without any unnecessary reinstalls.

I thought that the default behaviour is recursive. Is it not? (shudder) Or maybe this is only for cases when wrong packages have been removed?

Probably I am used with yum and apt and pacman is low level compared to them. This makes it difficult for me to follow the manual. So if pacman checks that dependencies of the package to be installed have the right version (which they should always have unless one has messed up with the packages using pacman's low level options) that is considered "conflict checking" and consequently advertised.

Last edited by doru001 (2013-01-29 15:14:52)

doru001 · 2013-01-29 15:55:53

Trilby wrote:

I sense a joke in there (number 1) that I'm just not getting, but if you have an unwillingness to read man pages or an inability to figure out what they mean, then there is really no way you can acheive number 3.

Manuals are not to be read from top to bottom. They are dictionaries. Good textbooks are very rare in mans.

cfr · 2013-01-29 22:29:28

doru001 wrote:

Trilby wrote:
I sense a joke in there (number 1) that I'm just not getting, but if you have an unwillingness to read man pages or an inability to figure out what they mean, then there is really no way you can acheive number 3.
resolving dependencies...
looking for inter-conflicts...
What is this message from `pacman -S package_name` really saying? We just established that pacman does not check for broken dependencies in the whole system before installs, and dependencies of the installed package are good from our current package list.

-S, --sync
Synchronize packages. Packages are installed directly from the ftp servers, including all dependencies required to run the
packages. For example, pacman -S qt will download and install qt and all the packages it depends on. If a package name exists
in more than one repo, the repo can be explicitly specified to clarify the package to install: pacman -S testing/qt. You can
also specify version requirements: pacman -S "bash>=3.2". (Quotes are needed, otherwise your shell interprets ">" as
redirection to file.)

There can be no conflicts, unless one has messed up the system.

This is false. I suggest that you read the wiki in conjunction with the man page. An example may also help e.g. see https://wiki.archlinux.org/index.php/De … iki:usrlib. Or two packages may conflict with each other just in the normal course of things. (pacman doesn't need to check the filesystem to know this if everything is running smoothly, though.) Or a file provided by one package may be moved to another package. Or... And I'm ignoring the possibilities introduced if you install AUR packages as well.

Seriously, go read the wiki. Play around with pacman.

Last edited by cfr (2013-01-29 22:29:58)

doru001 · 2013-01-31 17:40:26

cfr wrote:

This is false. I suggest that you read the wiki in conjunction with the man page. An example may also help e.g. see https://wiki.archlinux.org/index.php/De … iki:usrlib. Or two packages may conflict with each other just in the normal course of things. (pacman doesn't need to check the filesystem to know this if everything is running smoothly, though.) Or a file provided by one package may be moved to another package. Or... And I'm ignoring the possibilities introduced if you install AUR packages as well.
Seriously, go read the wiki. Play around with pacman.

What happens if a file is moved from one package to another and you `pacman -Syu`? If the former file owner is updated first, it should be ok.

Two packages which did not conflict with each other before `pacman -Syu` may conflict with each other after `pacman -Syu`, such that one of them will no longer be updated and the system will no longer be fully functional after update?

I begin to appreciate yum and apt.

Last edited by doru001 (2013-01-31 18:04:58)

Awebb · 2013-01-31 19:08:23

You make this look more complicated than it is. The only way for you to have such problems is by a) manually introducing them, b) dealing with old or broken AUR packages or using a broken/partially out of date mirror. There is no pinning, there is one version of each package, there are no weird dependencies and around three times a year, an update will require manual intervention, which will be announced at the news area of the home page. So as long as you do not fuck up the system, pacman will not need the --unfuck switch dpkg has.

doru001 · 2013-01-31 22:02:28

Awebb wrote:

You make this look more complicated than it is. The only way for you to have such problems is by a) manually introducing them, b) dealing with old or broken AUR packages or using a broken/partially out of date mirror. There is no pinning, there is one version of each package, there are no weird dependencies and around three times a year, an update will require manual intervention, which will be announced at the news area of the home page. So as long as you do not fuck up the system, pacman will not need the --unfuck switch dpkg has.

Between you and cfr, I side with you.

archbishop · 2013-02-01 00:06:35

Trilby wrote:

My advice is to *never* do a `pacman -Sy` - only do `pacman -Syu`..

for unknown reasons `pacman -Syu` doesn't work for me. it's `pacman -Syyu` that works, while to install something i must use `pacman -Sy package`, otherwise it won't install.

btw just upgraded to pacman-mirrorlist-20130131-1-any and all mirrors or are now disabled. tried to generate mirror from this page https://www.archlinux.org/mirrorlist/?c … _status=on it's still the same. any idea why? tia.

Arch Linux

#1 2013-01-27 13:35:27

arch upgrade with pacman -Su

#2 2013-01-27 13:47:16

Re: arch upgrade with pacman -Su

#3 2013-01-27 14:17:10

Re: arch upgrade with pacman -Su

#4 2013-01-27 14:43:19

Re: arch upgrade with pacman -Su

#5 2013-01-27 15:20:25

Re: arch upgrade with pacman -Su

#6 2013-01-27 15:21:30

Re: arch upgrade with pacman -Su

#7 2013-01-27 15:51:16

Re: arch upgrade with pacman -Su

#8 2013-01-27 16:13:49

Re: arch upgrade with pacman -Su

#9 2013-01-27 17:00:02

Re: arch upgrade with pacman -Su

#10 2013-01-27 17:08:48

Re: arch upgrade with pacman -Su

#11 2013-01-27 17:21:57

Re: arch upgrade with pacman -Su

#12 2013-01-27 17:39:27

Re: arch upgrade with pacman -Su

#13 2013-01-28 02:59:27

Re: arch upgrade with pacman -Su

#14 2013-01-28 09:17:34

Re: arch upgrade with pacman -Su

#15 2013-01-28 11:54:44

Re: arch upgrade with pacman -Su

#16 2013-01-28 13:06:11

Re: arch upgrade with pacman -Su

#17 2013-01-28 14:33:28

Re: arch upgrade with pacman -Su

#18 2013-01-28 15:17:16

Re: arch upgrade with pacman -Su

#19 2013-01-29 14:36:06

Re: arch upgrade with pacman -Su

#20 2013-01-29 15:55:53

Re: arch upgrade with pacman -Su

#21 2013-01-29 22:29:28

Re: arch upgrade with pacman -Su

#22 2013-01-31 17:40:26

Re: arch upgrade with pacman -Su

#23 2013-01-31 19:08:23

Re: arch upgrade with pacman -Su

#24 2013-01-31 22:02:28

Re: arch upgrade with pacman -Su

#25 2013-02-01 00:06:35

Re: arch upgrade with pacman -Su

Board footer