Overwriting files during an upgrade

gvre · 2004-03-12 13:10:46

Pacman ovewrites files during upgrade except if there is an option NoUpgrade
in pacman.conf. I think that it would be nicer if pacman could create a new file with .new extension like swaret does and display a warning about that. It is not easy to remember every .conf file i don't want to upgrade.
Are there any plans for this?

Gvre

Mr Green · 2004-03-12 13:51:48

It does....

Mr Green

Xentac · 2004-03-12 15:57:09

If you man pacman and read the handling config files section you'll see that's not entirely true.

shining · 2006-05-10 16:09:12

Yep, I've the same problem, and it's very annoying.
I don't like NoUpgrade stuff, and I think it's not needed because pacman should have a not stupid behavior as described in the man page.

original=X, current=Y, new=X
Both package versions contain the exact same file, but the one on the filesystem has been modified since. In this case, we leave the current file in place.

original=X, current=Y, new=Z
All three files are different, so we install the new file with a .pacnew extension and warn the user, so she can manually move the file into place after making any necessary customizations.

I'm not sure about the second case, but with the first case, the current file is overwritten, as opposed to what the doc says.
I see the wrong behavior at least for rc.conf and rc.local in initscripts.
Can someone explain me what's the need of NoUpgrade ?
According to pacman docs, a config file should be updated ONLY IF the default file wasn't modified by the user. This is imo a safe, and even recommended thing to do.

shining · 2006-05-10 16:54:40

ok so I looked at pacman code, and the manpage exactly match the code. I thought it could be a little bug, or the doc not up to date, but it isn't. There were these vprintf everywhere displaying informations, and in fact it was just the verbose output of pacman (I could have found it first ). Here is a part of it doing pacman -Sv filesystem :
checking md5 hashes for /etc/fstab
current: cc00c05c36418248c7c2ce555387db44
new: 0d3cfed6eacf21072e468bb7fe80cf07
original: cc00c05c36418248c7c2ce555387db44
action: installing new file

My tweaked fstab file has cc00c05c36418248c7c2ce555387db44 md5sum. But for some weird reason, pacman believes that was the original file too. So it overwrote my modified fstab file with the default one (try to boot after that..)
I hope this helps.

shining · 2006-05-10 17:31:56

but if I restore my fstab file, and run pacman -Sv filesystem again :

checking md5 hashes for /etc/fstab
current: cc00c05c36418248c7c2ce555387db44
new: 0d3cfed6eacf21072e468bb7fe80cf07
original: 0d3cfed6eacf21072e468bb7fe80cf07
action: leaving existing file in place

So now it has the correct original file, and I can't reproduce the bug.

brain0 · 2006-05-10 17:38:37

The md5sums are stored in /var/lib/pacman/local/*/files. On update, it will be changed, so you will never have a chance to reproduce the bug.

shining · 2006-05-10 17:52:08

Hehe, I was wondering, how the hell could it happen that the md5sum of my custom files is stored.
And I thought about the weird thing happening when using NoUpgrade.
So that's the answer
I just need to put the config file back in NoUpgrade, run pacman, so it stores the wrong md5sum.
Then put it away, and run pacman again.

shining · 2006-05-10 17:54:29

I still don't get what is the purpose of NoUpgrade besides breaking pacman it still looks like an useless hack to me, but if it's there, I guess other people don't think the same (maybe all?).

shining · 2006-05-10 18:07:21

it looks like the md5 is written after the config handling stuff, using the current file. The md5_pkg has been freed too. I think that the md5 of the file in the package should be stored no matter what happens, but I've troubles seeing the other effect of this.

phrakture · 2006-05-10 18:15:47

shining wrote:

I still don't get what is the purpose of NoUpgrade besides breaking pacman it still looks like an useless hack to me, but if it's there, I guess other people don't think the same (maybe all?).

How can it possibly be useless? It tells pacman "don't touch this file". You may want to look up the definition of "useless".

shining wrote:

it looks like the md5 is written after the config handling stuff, using the current file. The md5_pkg has been freed too. I think that the md5 of the file in the package should be stored no matter what happens, but I've troubles seeing the other effect of this.

If the md5sum is not stored, you lose the information for the "original" file. How do you expect to handle... well, anything. You'll have only 2 md5s to compare. If they're the same, overwrite. If they're different, make a pacnew. You lose alot of functionality.

The entire problem here stems from that fact that you "don't like NoUpgrade" - well, tough. NoUpgrade is there to prevent pacman from touching files. If you want it to mess with a file, remove it from the NoUpgrade entry. Otherwise, leave it there.

I really wish I understood all this confusion. NoUpgrade does exactly what it's intended to do.

shining · 2006-05-10 18:41:19

I'm not sure you understand the problem.
When NoUpgrade is used, the new config file is extracted in config.pacnew, which is fine, but the md5 of the current file is stored.
And this makes pacman behave wrongly. Pacman's assuming that the md5 stored represents the default config of a package, not a custom one.

shining · 2006-05-10 18:53:28

otherwise NoUpgrade would be fine if it actually used the original md5 (which then needs to be fixed anyway) to know if it needs to be extracted to foo.pacnew or not.

phrakture · 2006-05-10 19:58:39

So...um..... file it as a bug report? /me is confused

shining · 2006-05-11 17:01:58

Ok so I came with a patch that makes NoUpgrade behave just like I want. Currently, if a file is in NoUpgrade, pacman makes no distinction whether it's a config file (in backup section of PKGBUILD) or not, and that's the problem. So I just added this case, and I make it behave more smartly, it only extracts the pacnew file when needed (which is the thing that annoyed me in the first place, many pointless pacnew files).
What do you think ? (I've the weird feeling nobody will like it...).
But at least, if you want to safely move out config files from NoUpgrade, you need to considere this case, so that the correct md5sum is stored when installing/upgrading a package.

--- pacman-2.9.8/src/pacman.c.ori    2006-05-10 20:58:27.000000000 +0200
+++ pacman-2.9.8/src/pacman.c    2006-05-11 18:48:44.000000000 +0200
@@ -1936,7 +1936,7 @@
                 /* file already exists */
                 if(is_in(pathname, pmo_noupgrade)) {
                     notouch = 1;
-                } else {
+                }
                     if(!pmo_upgrade || oldpkg == NULL) {
                         nb = is_in(pathname, info->backup) ? 1 : 0;
                     } else {
@@ -1947,7 +1947,6 @@
                         }
                     }
                 }
-            }
 
             if(nb) {
                 char *temp;
@@ -1990,6 +1989,43 @@
                     vprint("  original: %sn", md5_orig);
                 }
 
+                if(notouch) {
+                    /* The config file is in NoUpgrade, so we don't touch it,
+                     * and only extract it as .pacnew when needed */
+                    int newconfig = 0;
+                    vprint("%s is a config file in NoUpgraden", expath);
+                if(!pmo_upgrade) {
+                    /* PM_ADD */
+
+                    /* if a file already exists with a different md5 hash,
+                     * then we will extract the config */
+                    if(!strcmp(md5_local, md5_pkg)) {
+                        vprint("config file is the same as current one, not extracting...n");
+                    } else {
+                        newconfig = 1;
+                    }
+                } else if(md5_orig) {                    
+                    /* PM_UPGRADE */
+
+                    /* If the config file has changed since the old one,
+                     * then we extract it */
+                    if(!strcmp(md5_orig, md5_pkg)) {
+                        vprint("config file is the same as the previous one, not extracting...n");
+                    } else {
+                        newconfig = 1;
+                    }
+                }
+                    if(newconfig) {
+                        vprint("  action: leaving file in place, installing new one as .pacnewn");
+                        strncat(expath, ".pacnew", PATH_MAX);
+                        logaction(stderr, "warning: extracting %s%s as %s", pmo_root, pathname, expath);
+                        if(copyfile(temp, expath)) {
+                            fprintf(stderr, "error: could not copy %s to %s: %sn", temp, expath, strerror(errno));
+                            errors++;
+                        }
+                    }
+                } else {
+                    /* The config file isn't in NoUpgrade, thus default config handling */
                 if(!pmo_upgrade) {
                     /* PM_ADD */
 
@@ -2041,6 +2077,7 @@
                         }
                     }
                 }
+                }
 
                 FREE(md5_local);
                 FREE(md5_pkg);

Arch Linux

#1 2004-03-12 13:10:46

Overwriting files during an upgrade

#2 2004-03-12 13:51:48

Re: Overwriting files during an upgrade

#3 2004-03-12 15:57:09

Re: Overwriting files during an upgrade

#4 2006-05-10 16:09:12

Re: Overwriting files during an upgrade

#5 2006-05-10 16:54:40

Re: Overwriting files during an upgrade

#6 2006-05-10 17:31:56

Re: Overwriting files during an upgrade

#7 2006-05-10 17:38:37

Re: Overwriting files during an upgrade

#8 2006-05-10 17:52:08

Re: Overwriting files during an upgrade

#9 2006-05-10 17:54:29

Re: Overwriting files during an upgrade

#10 2006-05-10 18:07:21

Re: Overwriting files during an upgrade

#11 2006-05-10 18:15:47

Re: Overwriting files during an upgrade

#12 2006-05-10 18:41:19

Re: Overwriting files during an upgrade

#13 2006-05-10 18:53:28

Re: Overwriting files during an upgrade

#14 2006-05-10 19:58:39

Re: Overwriting files during an upgrade

#15 2006-05-11 17:01:58

Re: Overwriting files during an upgrade

Board footer