Package: debhelper
Severity: wishlist

Hi,

in the openttd-opengfx package, I'm using dh_link to replace some
upstream-installed files with symlinks. To prevent accidentally linking
to the wrong file, I now explicitly diff the files before creating the
link. It would be nice if dh_link could handle that.

I can imagine an option that checks whether the to-be-created link and
the target already exist and if so, whether they are equal. I can
imagine four modes:

 1. Always create the link. This is the current behaviour.
 2. When both files exist and are not equal, do nothing. In all other
    cases, create the link.
 3. When both files exist and are not equal, abort with an error. In all
    other cases, create the link.
 4. When both files exist and are not equal, or either file does not
    exist, abort with an error. Only if both files exist and are equal,
    create the link.

I suspect that in most cases, the link will not overwrite any existing
files, so 2. is useful as a safeguard against accidentally overwriting
a non-identical file.

In my case, I'm letting the upstream Makefile first install files, and
then replace them with a symlink. In that case, I want to *only* replace
files and not create new links, so I would need 3.


One complication in implementing this would be cross-package links. For
implementing any of 2., 3. or 4. above, you need to be able to resolve
the target of the link. If that lives in another package, this is
tricky. I can imagine two flavours of this:
 - Links to other binary packages resulting from the currently built
   source package. Maybe dh can resolve those by looking in all
   available install dirs for the file. I guess this *might* result in
   multiple versions of the same file, which should then *all* be
   identical.
 - Links to unrelated binary packages (e.g. links to
   /usr/share/common-licenses). These could maybe be resolved against
   the build system (this is what I do for the license right now), but I
   don't think this can be made reliable, so this is probably better to
   not support at all.

Gr.

Matthijs

Reply via email to