[pacman-dev] difficult symlink puzzle, part 2.
dpmcgee at gmail.com
Mon Aug 20 16:12:55 EDT 2007
On 8/5/07, Andrew Fyfe <andrew at 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 at 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.
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
More information about the pacman-dev