[pacman-dev] Adding a new config file to a package (e.g. mercurial file conflict)
I did an -Syu on my Arch box today, which updated Mercurial, and the new package contains a /etc/mercurial/hgrc file. I had already created one on my system, and the old package did not contain one, so I got a file conflict. (54/54) checking package integrity [######################] 100% (54/54) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) mercurial: /etc/mercurial/hgrc exists in filesystem Errors occurred, no packages were upgraded. So instead, I had to -Sf the package, which installs the file with a pacnew: (1/1) checking package integrity [######################] 100% (1/1) checking available disk space [######################] 100% (1/1) upgrading mercurial [######################] 100% warning: /etc/mercurial/hgrc installed as /etc/mercurial/hgrc.pacnew This behavior is a bit...odd. We don't like people using -f, and they are trained to assume the worst, so most would not expect the backup logic to still kick into effect. A pactest is below, but I'm asking for thoughts on expected behavior in this case. Many possibilities listed for completeness, some of which are just plain dumb. 1) Keep as is with file conflict error, require -Sf, keep backing up file to pacnew 2) Keep as is with file conflict error, require -Sf, don't backup (this is stupid) 3) Don't error at all, treat as a normal backup case except pretend old file is the same as /dev/null (aka empty). 4) Same as (3), but make the pacnew warning message slightly different, e.g. "%s is new in package, installed as %s" or something. 5) Something like (3) or (4) but don't even treat it the same as an empty file, treat it as never matching anything. My vote is 3 or 4, not that we are a democracy. :) -Dan self.description = "Upgrade a package, with a file entering the pkg in 'backup'" lp = pmpkg("dummy") lp.files = ["usr/bin/dummy"] self.addpkg2db("local", lp) p = pmpkg("dummy", "1.0-2") p.files = ["usr/bin/dummy", "etc/dummy.conf"] p.backup = ["etc/dummy.conf"] self.addpkg(p) self.args = "-U %s" % p.filename() self.addrule("PACMAN_RETCODE=0") self.addrule("PKG_VERSION=dummy|1.0-2") self.addrule("!FILE_PACSAVE=etc/dummy.conf") self.addrule("FILE_PACNEW=etc/dummy.conf") self.addrule("FILE_EXIST=etc/dummy.conf")
On Thu, Jul 14, 2011 at 12:28:31PM -0500, Dan McGee wrote:
I did an -Syu on my Arch box today, which updated Mercurial, and the new package contains a /etc/mercurial/hgrc file. I had already created one on my system, and the old package did not contain one, so I got a file conflict.
(54/54) checking package integrity [######################] 100% (54/54) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) mercurial: /etc/mercurial/hgrc exists in filesystem Errors occurred, no packages were upgraded.
So instead, I had to -Sf the package, which installs the file with a pacnew:
(1/1) checking package integrity [######################] 100% (1/1) checking available disk space [######################] 100% (1/1) upgrading mercurial [######################] 100% warning: /etc/mercurial/hgrc installed as /etc/mercurial/hgrc.pacnew
This behavior is a bit...odd. We don't like people using -f, and they are trained to assume the worst, so most would not expect the backup logic to still kick into effect. A pactest is below, but I'm asking for thoughts on expected behavior in this case. Many possibilities listed for completeness, some of which are just plain dumb.
1) Keep as is with file conflict error, require -Sf, keep backing up file to pacnew 2) Keep as is with file conflict error, require -Sf, don't backup (this is stupid)
3) Don't error at all, treat as a normal backup case except pretend old file is the same as /dev/null (aka empty).
This is where I sit. You shouldn't have to force the install, and the new file from the backup array should be dropped in place with a .pacnew extension. IMO, you get the best user experience going this route -- you don't need to go out of your way to do the upgrade, and there's notification about the new file being dropped in. I don't think there's any need to create a different message. It's sort of a special case, but I don't think it needs any special handling. d
4) Same as (3), but make the pacnew warning message slightly different, e.g. "%s is new in package, installed as %s" or something. 5) Something like (3) or (4) but don't even treat it the same as an empty file, treat it as never matching anything.
My vote is 3 or 4, not that we are a democracy. :)
-Dan
self.description = "Upgrade a package, with a file entering the pkg in 'backup'"
lp = pmpkg("dummy") lp.files = ["usr/bin/dummy"] self.addpkg2db("local", lp)
p = pmpkg("dummy", "1.0-2") p.files = ["usr/bin/dummy", "etc/dummy.conf"] p.backup = ["etc/dummy.conf"] self.addpkg(p)
self.args = "-U %s" % p.filename()
self.addrule("PACMAN_RETCODE=0") self.addrule("PKG_VERSION=dummy|1.0-2") self.addrule("!FILE_PACSAVE=etc/dummy.conf") self.addrule("FILE_PACNEW=etc/dummy.conf") self.addrule("FILE_EXIST=etc/dummy.conf")
On 07/14/2011 07:44 PM, Dave Reisner wrote:
On Thu, Jul 14, 2011 at 12:28:31PM -0500, Dan McGee wrote:
3) Don't error at all, treat as a normal backup case except pretend old file is the same as /dev/null (aka empty). This is where I sit. You shouldn't have to force the install, and the new file from the backup array should be dropped in place with a .pacnew extension. IMO, you get the best user experience going this route -- you don't need to go out of your way to do the upgrade, and there's notification about the new file being dropped in. I don't think there's any need to create a different message. It's sort of a special case, but I don't think it needs any special handling.
d
Agreed, this sounds like the right thing to do.
The bulk of this commit is adding new tests to ensure the new behavior
works without disrupting old behavior. This is a relatively sane maneuver
when a package adds a conf file (e.g. '/etc/mercurial/hgrc') that was
not previously in the package, but it is placed in the backup array. In
essence, we can treat the existing file as having always been a part of
the package and do our normal compare/install as pacnew logic checks.
Signed-off-by: Dan McGee
participants (4)
-
Dan McGee
-
Dan McGee
-
Dave Reisner
-
Jakob Gruber