Hi! On Tue, 2014-09-02 at 09:30:25 -0700, Don Armstrong wrote: > On Thu, 21 Aug 2014, Guillem Jover wrote: > > The dpkg-maintscript-helper usage in this package is broken, because > > it's using a relative symlink target. The dpkg-maintscript-helper has > > been doing sanity checks to see if the canonicalized symlink targe > > (from «readlink -f») matches the passed symlink target argument, which > > will just not match, and not perform the switch. > > This doesn't match what the documentation still says (as of 1.17.13)[1], > and also seems sort of backwards to me.
Hmm, this was supposed to be fixed with the upload that made the check coherent with the implementation, this is what the man page says for the symlink to directory switch (which is what lilypond-doc is using): pathname is the absolute name of the old symlink (the path will be a directory at the end of the installation) and old-target the absolute target name of the former symlink at pathname. or is there something else I missed on the update (perhaps the omitted stuff referenced by [1]?). > The package can control the symlink's target (after all, that's what the > symlink did), but has less control over the place in the filesystem > that the symlink eventually points to. [In the instant case, we've > previously done a /usr/doc to /usr/share/doc migration, which would have > worked seamlessly if the target was checked, but would have required > more changes if the cannonical target was checked. Sure, it seems and it is a bit backwards, but that's because the initial implementation could only handle absolute symlink targets for dir_to_symlink, so “it seemed to make more sense” to have both be symmetric. When the dir_to_symlink got fixed to also accept relative symlinks, I actually got a bit bothered by the new asymmetry, but… > > Starting with dpkg 1.17.13 the program will error out on such > > parameters (the documentation has been updated too now), so the package > > becomes uninstallable/unremovable. Please switch to use an absolute > > path for the symlink target. > > I'll do this for the time being, but either the documentation needs to > be fixed, or the implementation changed. [An easy change would be to > check both readlink -f or just readlink.] … neither me nor Helmut did think of this obvious solution, I don't know why!? maybe just because we had our minds elsehwere during the Bootstrap Sprint :), I'll try to recall if there was actually any problem. But otherwise, I'll just be adding relative symlink support to symlink_to_dir in dpkg 1.17.14, but be aware that previous dpkg version will either accept them but not perform the actual switch or outright refuse them. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
