[pacman-dev] difficult symlink puzzle, part 2.
Hi! If I didn't misunderstood conflict.c then fileconflict check fails in the following case (pacman -A pkg1 pkg2): pkg1 contains: /dir1/file pkg2 contains: /dir2/file, if /dir1 and /dir2 exists on filesystem, and /dir2 is a symlink pointing to /dir1. Much more difficult problem (and fortunately much rarer), if pkg2 creates the /dir2 symlink, so it didn't exist before the transaction. Any tests/feedbacks appreciated... How is this handled in other package managers? Bye, ngaba PS: a possible semi-solution: pacman shouldn't stop/overwrite in case of these "hidden" fileconflict errors, it extract /dir2/file as /dir2/file.pkg2.pacnew and do something at the end of the transaction. (Speed is a big limiting factor here.)
On Fri, Aug 03, 2007 at 12:15:56AM +0200, Nagy Gabor wrote:
Hi!
If I didn't misunderstood conflict.c then fileconflict check fails in the following case (pacman -A pkg1 pkg2): pkg1 contains: /dir1/file pkg2 contains: /dir2/file, if /dir1 and /dir2 exists on filesystem, and /dir2 is a symlink pointing to /dir1. Much more difficult problem (and fortunately much rarer), if pkg2 creates the /dir2 symlink, so it didn't exist before the transaction. Any tests/feedbacks appreciated...
If it's possible to extend pactest for this stuff, it could probably help.
How is this handled in other package managers?
I tried to look at dpkg code, I didn't understand anything :p
PS: a possible semi-solution: pacman shouldn't stop/overwrite in case of these "hidden" fileconflict errors, it extract /dir2/file as /dir2/file.pkg2.pacnew and do something at the end of the transaction. (Speed is a big limiting factor here.)
dpkg seems to use suffix as well, .dpkg-new and .dpkg-tmp. dpkg-new is apparently used for config files, and dpkg-tmp, I'm not sure. You can grep for these strings in dpkg source: http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5.tar.gz
Xavier wrote:
On Fri, Aug 03, 2007 at 12:15:56AM +0200, Nagy Gabor wrote:
Hi!
If I didn't misunderstood conflict.c then fileconflict check fails in the following case (pacman -A pkg1 pkg2): pkg1 contains: /dir1/file pkg2 contains: /dir2/file, if /dir1 and /dir2 exists on filesystem, and /dir2 is a symlink pointing to /dir1. Much more difficult problem (and fortunately much rarer), if pkg2 creates the /dir2 symlink, so it didn't exist before the transaction. Any tests/feedbacks appreciated...
If it's possible to extend pactest for this stuff, it could probably help.
How is this handled in other package managers?
I tried to look at dpkg code, I didn't understand anything :p
PS: a possible semi-solution: pacman shouldn't stop/overwrite in case of these "hidden" fileconflict errors, it extract /dir2/file as /dir2/file.pkg2.pacnew and do something at the end of the transaction. (Speed is a big limiting factor here.)
dpkg seems to use suffix as well, .dpkg-new and .dpkg-tmp. dpkg-new is apparently used for config files, and dpkg-tmp, I'm not sure. You can grep for these strings in dpkg source: http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5.tar.gz
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
When installing a package dpkg moves the old file to *.dpkg-tmp, then extracts the new file (I think config files are extracted as .dpkg-new, can't remember off hand). Then the old file is removed later. This is a far better method than pacmans it allows dpkg to rollback a package install if there is an error. Andrew
On 8/5/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Xavier wrote:
On Fri, Aug 03, 2007 at 12:15:56AM +0200, Nagy Gabor wrote:
Hi!
If I didn't misunderstood conflict.c then fileconflict check fails in the following case (pacman -A pkg1 pkg2): pkg1 contains: /dir1/file pkg2 contains: /dir2/file, if /dir1 and /dir2 exists on filesystem, and /dir2 is a symlink pointing to /dir1. Much more difficult problem (and fortunately much rarer), if pkg2 creates the /dir2 symlink, so it didn't exist before the transaction. Any tests/feedbacks appreciated...
If it's possible to extend pactest for this stuff, it could probably help.
How is this handled in other package managers?
I tried to look at dpkg code, I didn't understand anything :p
PS: a possible semi-solution: pacman shouldn't stop/overwrite in case of these "hidden" fileconflict errors, it extract /dir2/file as /dir2/file.pkg2.pacnew and do something at the end of the transaction. (Speed is a big limiting factor here.)
dpkg seems to use suffix as well, .dpkg-new and .dpkg-tmp. dpkg-new is apparently used for config files, and dpkg-tmp, I'm not sure. You can grep for these strings in dpkg source: http://ftp.debian.org/debian/pool/main/d/dpkg/dpkg_1.14.5.tar.gz
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
When installing a package dpkg moves the old file to *.dpkg-tmp, then extracts the new file (I think config files are extracted as .dpkg-new, can't remember off hand). Then the old file is removed later. This is a far better method than pacmans it allows dpkg to rollback a package install if there is an error.
Andrew
Late on this reply, but I'll chime in anyway. Post 3.1 release, we could definitely do a rewrite of the way upgrade transactions work, with regard to both file installation/removal and that stupid fake REMOVE transaction business. It might be a little hackathon to get it all working but I'm sure it would be 300% cleaner than what we have now. -Dan
participants (4)
-
Andrew Fyfe
-
Dan McGee
-
Nagy Gabor
-
Xavier