Pacman 3: Ready To Move

pjeremy · 2007-05-11 07:19:24

fakeroot appears to be another dependency of pacman 3 which won't get downloaded with pacman -Syu.
I already had libarchive and libdownload.

sudo pacman -Syu
:: pacman has detected a newer version of the "pacman" package.
:: It is recommended that you allow pacman to upgrade itself
:: first, then you can re-run the operation with the newer version.
::
:: Upgrade pacman first? [Y/n] y
error: unresolvable dependencies:
  pacman: requires fakeroot but it is not in the sync db

pacman -Sy pacman has no problem getting fakeroot and updating pacman.

phrakture · 2007-05-11 07:35:22

Good catch. I forgot about fakeroot. That's part of the reason why -Sy is recommended in the originating news posting.

Kardell · 2007-05-11 08:47:15

Indeed

pacman -Sy pacman

did the job.
No further problems with dependencies. ;-)

ruimoura · 2007-05-11 10:01:37

Kardell wrote:

Indeed
pacman -Sy pacman
did the job.
No further problems with dependencies. ;-)

One more here. Upgraded with no problems at all

funkyou · 2007-05-11 11:44:50

That was a smooth update

Blame my english, but i dont understand this line:

>>> Performing one-time reset of NoUpgrade md5sums. After this reset
>>> you are able to remove all NoUpgrade lines of already protected
>>> files from pacman.conf.

berbae · 2007-05-11 12:34:44

After reading 'man pacman' the 'HANDLING CONFIG FILES' part at the end, I understand that once the 3 md5sums has been calculated for the files in a NoUpgrade line, the files are now considered protected, and so it is not necessary to keep them in the NoUpgrade line of the /etc/pacman.conf file.
I think that to add another file not to upgrade after that, it is necessary to put its name in a new NoUpgrade line, to let pacman do the md5sums calculations for that file, and to delete the line after that, as it is only necessary once. It is what I understand of the 'one-time reset of NoUpgrade md5sums'.

Am I right in that understanding ?

Personally, I deleted the NoUpgrade lines after the pacman upgrade.
But I keep a backup of the files not to upgrade, in case something goes wrong with the pacman handling of the config files.

Snarkout · 2007-05-11 15:17:01

>>> PLEASE READ THE FOLLOWING!
>>> The makepkg.conf syntax has changed, please note the new format
>>> when merging the pacnew file with your old configuration.

I have an /etc/makepkg.conf file, but no pacsave or pacnew of the same file. I've never screwed with the default settings, but I'd still expect one or the other of these to exist if I'm being told that makepkg.conf is changing and I need to look at my old and new ones. Should I worry about this?

phrakture · 2007-05-11 15:28:28

Snarkout wrote:

>>> PLEASE READ THE FOLLOWING!
>>> The makepkg.conf syntax has changed, please note the new format
>>> when merging the pacnew file with your old configuration.
I have an /etc/makepkg.conf file, but no pacsave or pacnew of the same file. I've never screwed with the default settings, but I'd still expect one or the other of these to exist if I'm being told that makepkg.conf is changing and I need to look at my old and new ones. Should I worry about this?

Read the 'HANDLING CONFIG FILES' section - if you have never changed your file from the defaults (the md5sum matches when it was installed), it is overwritten without the need for interaction.

phrakture · 2007-05-11 15:32:32

funkyou wrote:

That was a smooth update
Blame my english, but i dont understand this line:
>>> Performing one-time reset of NoUpgrade md5sums. After this reset
>>> you are able to remove all NoUpgrade lines of already protected
>>> files from pacman.conf.

berbae wrote:

After reading 'man pacman' the 'HANDLING CONFIG FILES' part at the end, I understand that once the 3 md5sums has been calculated for the files in a NoUpgrade line, the files are now considered protected, and so it is not necessary to keep them in the NoUpgrade line of the /etc/pacman.conf file.
I think that to add another file not to upgrade after that, it is necessary to put its name in a new NoUpgrade line, to let pacman do the md5sums calculations for that file, and to delete the line after that, as it is only necessary once. It is what I understand of the 'one-time reset of NoUpgrade md5sums'.
Am I right in that understanding ?
Personally, I deleted the NoUpgrade lines after the pacman upgrade.
But I keep a backup of the files not to upgrade, in case something goes wrong with the pacman handling of the config files.

Here's the quick rundown.

The entries in NoUpgrade in pacman.conf are redundant, as all packages should maintain that information in the backup=() array, and they all do. So it is safe to remove the NoUpgrade entires, as it is all handled by backup=() arrays.

Regarding the "reset" - pacman 2.X had a minor bug where it inserted the wrong md5sum into the DB for NoUpgrade files. This causes a problem when removing the NoUpgrade entries, as it tells pacman that it is safe to overwrite the file on disk (and that may not be true). So, in order to be safe about it, the md5sums of all old NoUpgrade files are set to all zeros - this way it forces pacman to back it up. The worst case scenario is that you have a few extra .pacnew files laying around once you install the package again.

lanrat · 2007-05-11 15:55:09

In the default makepkg.conf file from pacman 3.0.4-1 in the OPTIONS array the default setting is libtool while the comment say it should be !libtool (delete .la files). Bug report

funkyou · 2007-05-11 19:03:06

thanks berbae and phrakture, its now clear for me

soloport · 2007-05-11 20:43:39

Hot damn! That's a fast pacman. Big thanks to phrakture (and other devs?) Very nicely done.

phrakture · 2007-05-11 21:09:14

soloport wrote:

Hot damn! That's a fast pacman. Big thanks to phrakture (and other devs?) Very nicely done.

And Dan (toofishes) - don't forget him.

We also had quite a lot of contributors, so special thanks go out to:

Judd Vinet <jvinet@zeroflux.org>
Aurelien Foret <aurelien@archlinux.org>
Dan McGee <dan@archlinux.org>
Jürgen Hötzel <juergen@archlinux.org>
Mikls Vajna <vmiklos@frugalware.org>
Christian Hamar <krics@linuxforum.hu>
Josh Wheeler <deltalima@gmail.com>
David Kimpe <DNAku@frugalware.org>
James Rosten <seinfeld90@gmail.com>
Roman Kyrylych <Roman.Kyrylych@gmail.com>
Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com>
Nagy Gabor <ngaba@petra.hos.u-szeged.hu>
Chantry Xavier <xav@chantry.homelinux.org>
Andrew Fyfe <andrew@neptune-one.net>
Scott Horowitz <stonecrest@gmail.com>

And the translators:

Nam <37i11@altern.org> (french)
Pierre Schmitz <pierre@archlinux.de> (german)
Juan Pablo González T <lord_jotape@yahoo.com.ar> (spanish)
Mateusz Jędrasik <m.jedrasik@gmail.com> (polish)
Matthias Gorissen <siquame@web.de> (german)
Владимир Байраковский <4rayven@gmail.com> (russian)

And there's probably a lot more I missed.

Thanks a lot guys!

berbae · 2007-05-11 22:31:27

Thanks phrakture for the explanations.
I misunderstood the subject of the NoUpgrade lines.
Now I think it is clear to me :
The NoUpgrade lines are no more necessary in the /etc/pacman.conf file because the files not to be upgraded are taken care of in the backup=() arrays of each package. So there is no need to add new NoUpgrade lines for config files in the standard packages.
The 'one-time reset of NoUpgrade md5sums' message concerns only the upgrade from pacman 2.x to 3.0, as the md5sums of all old NoUpgrade files were wrong in pacman 2.x, and it was necessary to set them to zeros only once after the upgrade to pacman 3.0.
I think I got it right now.

Thanks to all the devs and contributors for their good work in the development of this new pacman release which will be great, I am sure.

Last edited by berbae (2007-05-12 09:44:26)

Bebo · 2007-05-12 13:17:44

I have yet another question on the NoUpgrade lines. You say that the backup arrays "should" take care of this. So, if a packager _forgets_ to add for instance some config file in /etc to the backup array, then this file would be overwritten in an upgrade. Or? (What I mean is that I have to trust someone to not have a memory lapse to not screw my config files )

berbae · 2007-05-12 14:33:49

Hi Bebo
I think you can be right about a packager forgetting to put a config file in the backup=() array, but also that the risk is very limited because there is not a great number of config files in a given package and it is easy to know which config files can be modified by a user, and so must be kept and the new config file installed with the .pacnew extension.
So the risk seems to me almost zero with the official packages.

And it's always a good practice to have backups of the most important files in a running system. So even if a problem occurs it is easily solved.

Last edited by berbae (2007-05-12 14:34:50)

Grimn · 2007-05-12 14:48:36

How do we merge the old pacman files with the new .pacnew files? I had the impression when I upgraded pacman there was a command there to emrge them but I forgot to execute it.

phrakture · 2007-05-13 00:14:02

Merging files needs to be done manually. You need to look at both files and check the changes. In general, this isn't all that hard. If you know vim, I'd recommend using vimdiff to compare and merge.

shining · 2007-05-13 10:49:03

Bebo wrote:

I have yet another question on the NoUpgrade lines. You say that the backup arrays "should" take care of this. So, if a packager _forgets_ to add for instance some config file in /etc to the backup array, then this file would be overwritten in an upgrade. Or? (What I mean is that I have to trust someone to not have a memory lapse to not screw my config files )

That was already the case before, the pacman.conf only contained a few NoUpgrade entries for the most critical files.
So the other configs already had to be in the backup array for not being lost on upgrade.
And yes, obviously, you have to trust the people who made all the parts of Archlinux you are using (that is, archlinux dev and packagers, but also dev of all softwares used)
If you edited some config files of package foo you care about, then check pacman -Qii foo.
It will show you its backup files. If one package is missing some config files there, then report it.

If you really care about a config file, you should already have a backup on an external storage anyway, because you never know what might happen (user error, filesystem corruption, hard drive failure, ...)

arooaroo · 2007-05-13 10:52:56

Woo hoo! pacman 3 is quite impressive. Very responsive indeed. I recently reinstalled Arch 0.8 on my laptop and was using 2.9.8. This time I opted for ext3 FS rather than Reiser which I've tended to use in the past and pacman was really slow. So I was extremely relieved to see pacman3 alleviate that issue as it's pretty darn speedy.

Nice work

Bebo · 2007-05-13 12:05:26

@berbae and shining: Thanks for your answers, I suspected they would be coming

My question was due to the advice after/during upgrading to pacman 3, that the NoUpgrade lines could be removed after the md5sum reset. After reading that message, I was kind of hoping that pacman 3 had some new amazing automagical way to make sure config files were never overwritten during upgrades (maybe, like, protecting all files in /etc automatically). If a config file is not in the backup array, then I wouldn't know that until it's "too late" - I don't do pacman -Qii for every package I have before upgrading.

Very well then, I'll continue using my pretty long line of NoUpgrade lines (and doing backups, needless to say). Yes, the risks are slim, but I'm lazy. (For instance, /etc/issue is not in the backup array in the filesystem package. Probably seems like a very unnecessary file to put in the backup array to the packager (and most other people ), but I don't want the clear screen stuff...)

shining · 2007-05-13 21:15:13

Bebo wrote:

Very well then, I'll continue using my pretty long line of NoUpgrade lines (and doing backups, needless to say). Yes, the risks are slim, but I'm lazy. (For instance, /etc/issue is not in the backup array in the filesystem package. Probably seems like a very unnecessary file to put in the backup array to the packager (and most other people ), but I don't want the clear screen stuff...)

Ah well, I guess /etc/issue might be a good example of what to put in NoUpgrade. But have you really many files like that?
Personally, I want to have as many files auto updated as possible. For example, issue was recently changed to have the Duke name, and it was replaced directly, since it wasn't in NoUpgrade, and I hadn't edited it.
Some changes to config files are more important, some are fixed, other get improved, or have new features,... In some cases, configs even radically change and old configs would break with the new program. Avoiding any upgrades to files in /etc/ seems like a bad idea to me.
Anyway, I'm very happy with the way it works. All files I didn't edit are auto updated, and I'm left with a few .pacnew files to merge when a config file I edited was updated. (On 124 config files in backup installed on my system, I only edited 31 of them)
Also, what is annoying with files in NoUpgrade, it's that they are extracted as .pacnew no matter what when you upgrade the package, even if these files don't contain anything new.

Bebo · 2007-05-13 21:51:14

shining, well, I have 32 NoUpgrade files, including those "default" ones. As for the .pacnew files I have a script for that, which I run whenever I see the warning that a file has been added with a .pacnew extension - as well as on sporadic un-called for occassions. The script lets me deal with the .pacnew files in a simple way, and if there have been (massive) changes to a config file, I just merge them manually. I'm happy with how things are too, I was just a bit surprised to be advised to remove the NoUpgrade lines. I totally agree with you, especially your last point

McQueen · 2007-05-13 22:20:02

I kept a few NoUpgrade entries in pacman.conf (such as /etc/issue).

Otherwise, I use the following:
1. Dotpac (AUR) to identify/view/manage new config files.
2. Unison (Extra) to sync changes and restore from backups.

shining · 2007-05-13 22:28:36

Bebo wrote:

I was just a bit surprised to be advised to remove the NoUpgrade lines. I totally agree with you, especially your last point

I'm confused. If you agree with the last point, then removing config files that are already in backup array from NoUpgrade will fix it
You should only have a few files left in NoUpgrade, the ones that aren't in backup, like etc/issue.

Arch Linux

#26 2007-05-11 07:19:24

Re: Pacman 3: Ready To Move

#27 2007-05-11 07:35:22

Re: Pacman 3: Ready To Move

#28 2007-05-11 08:47:15

Re: Pacman 3: Ready To Move

#29 2007-05-11 10:01:37

Re: Pacman 3: Ready To Move

#30 2007-05-11 11:44:50

Re: Pacman 3: Ready To Move

#31 2007-05-11 12:34:44

Re: Pacman 3: Ready To Move

#32 2007-05-11 15:17:01

Re: Pacman 3: Ready To Move

#33 2007-05-11 15:28:28

Re: Pacman 3: Ready To Move

#34 2007-05-11 15:32:32

Re: Pacman 3: Ready To Move

#35 2007-05-11 15:55:09

Re: Pacman 3: Ready To Move

#36 2007-05-11 19:03:06

Re: Pacman 3: Ready To Move

#37 2007-05-11 20:43:39

Re: Pacman 3: Ready To Move

#38 2007-05-11 21:09:14

Re: Pacman 3: Ready To Move

#39 2007-05-11 22:31:27

Re: Pacman 3: Ready To Move

#40 2007-05-12 13:17:44

Re: Pacman 3: Ready To Move

#41 2007-05-12 14:33:49

Re: Pacman 3: Ready To Move

#42 2007-05-12 14:48:36

Re: Pacman 3: Ready To Move

#43 2007-05-13 00:14:02

Re: Pacman 3: Ready To Move

#44 2007-05-13 10:49:03

Re: Pacman 3: Ready To Move

#45 2007-05-13 10:52:56

Re: Pacman 3: Ready To Move

#46 2007-05-13 12:05:26

Re: Pacman 3: Ready To Move

#47 2007-05-13 21:15:13

Re: Pacman 3: Ready To Move

#48 2007-05-13 21:51:14

Re: Pacman 3: Ready To Move

#49 2007-05-13 22:20:02

Re: Pacman 3: Ready To Move

#50 2007-05-13 22:28:36

Re: Pacman 3: Ready To Move

Board footer