[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: symlink vs. directory "conflicts"

On Thu, 2012-10-04 at 01:53:56 -0700, Russ Allbery wrote:
> Andreas Beckmann <debian@abeckmann.de> 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?
> Yes.


> 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.


Reply to: