Re: symlink vs. directory "conflicts"
On Thu, 2012-10-04 at 01:53:56 -0700, Russ Allbery wrote:
> Andreas Beckmann <email@example.com> writes:
> > So what is the general recommendation about packages that ship files
> > over symlinked directories? Should this be forbidden because it opens
> > cans of worms?
> This sort of thing:
> > foo ships /usr/share/foo/foo.dat
> > bar ships /usr/share/foobar/bar.dat
> > /usr/share/foo -> foobar
> is clearly broken and can't ever be the situation we actually want to have
> in the archive. In addition to the problem you name involving bar moving
> the symlink, what happens if bar adds a file /usr/share/foobar/foo.dat?
> Does dpkg even correctly realize that the two packages conflict because
> they both ship the same file (just via different paths)?
Nope, dpkg does not currently have enough information (missing
metadata) to know if a path was shipped in the package as a directory
or as a symlink, and to be able to distinguish between admin modified
directory←→symlinks. AFAIR there's already a bug report about this kind
of situation on dpkg.
> The trick, of course, will be finding this sort of problem so that
> maintainers can avoid it proactively rather than having to react to bugs
> or QA reports. I'm not sure if we'll be able to do that, which would be
> unfortunate. But I think it's fairly clear that situation isn't sensible
> or stable.
For the dpkg side of things I'm planning on working on the database
metadata tracking for 1.17.x, which is needed for other stuff, and
as a side effect this kind of situation could be handled. For now
something else will be needed to spot this kind of problems though.