On Wed, Jul 3, 2013 at 9:04 AM, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: >> Shortly, piuparts.debian.org will be elevating the broken symlink test >> in sid from a warning to an error status. In advance of that, bugs >> submissions are planned against packages which are responsible for >> such links. > > I don't think this is a good idea. > >> These are sometimes triggered because a Recommended or reverse >> dependency package owning the symlink target file is not yet >> installed. This type of failure mode needs to be eliminated so >> that other symlink problems become more visible. In this case, >> the problem can be resolved by creating a trigger for the >> target file. See the dpkg triggers documentation[1] and example >> on the net[2] for implementation details. > > I think this should be dealt with by making the diagnosis more > sophisticated, not by introducing substantial additional complexity > into packages. Alternatively, you should implement an override > facility. > > There is IMO nothing wrong with package X containing a symlink to a > file present in Y, if there is some plausible explanation and the > broken link doesn't cause harmful behaviour on the user's system. > > If X recommends (or even suggests) Y this probably means that there is > such an explanation, but it seems to me that this situation might > occur even if there is no declared relationship between X and Y (for > example, one of the packages might contain a plugin for the other, > implemented by dropping a symlink into an appropriate directory). > > Ian. >
Ok, here is my case. In short: - My read of the Policy says that broken shared library symlinks represent a violation. - The 'override facility' would be problematic. The reliability of an automated facility would be suspect (there is a reason that there is a piuparts 'dependency-failed-testing' state instead of an automated means to compensate for dependency failures). A manual facility implies inspection of every release of affected packages. - In either case, an explanation of, for instance, link X->Y is resolved by installing Recommended package Z doesn't IMO answer the question of whether or not the breakage is benign. Piuparts.d.o is the wrong place to place this responsibility. - IMO, creating broken symlinks is a bad practice. The piuparts broken symlink test can find significant problems in packages. For the test to be useful, the issues it finds need to be addressed at the source. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caohcdna1kd20so58b2eyf2eabz3ug9j2jyxv4m-oydsjlu+...@mail.gmail.com
