I think that best course of action would be to wait till January and fill an upstream issue in an upstream gitlab for BIND ;)
I think this is reasonable, but what about we change this in an upstream first and then backport the change? O. -- Ondřej Surý <ond...@sury.org> On Wed, Dec 13, 2017, at 20:18, Daniel Kahn Gillmor wrote: > Hi all-- > > On Wed 2017-12-13 16:00:26 +0100, Bernhard Schmidt wrote: > > Control: tags -1 + wontfix > > I don't think this is a good resolution for #593940, and i hope we can > revert it. > > > On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote: > > > >> Package: bind9utils > >> Version: 1:9.7.1.dfsg.P2-2 > >> Severity: normal > >> > >> Why are dnssec-{keygen,signzone} in /usr/sbin? They are perfectly usable > >> from normal user accounts and zone signing actions are not exactly carried > >> through by "system binaries" as specified by the FHS. > > > > This is where upstream (and every other distribution) puts these > > files. > > By this argument, we would never fix any upstream bugs at all :) Debian > has the opportunity to lead the way here. > > > Changing this now would break compatibity with everyone else and > > existing scripts referencing the full path name. > > Debian policy §6.1 (about maintainer scripts) says: > > Programs called from maintainer scripts should not normally have a > path prepended to them. Before installation is started, the package > management system checks to see if the programs ldconfig, > start-stop-daemon, and update-rc.d can be found via the PATH > environment variable. Those programs, and any other program that one > would expect to be in the PATH, should thus be invoked without an > absolute pathname. Maintainer scripts should also not reset the > PATH, though they might choose to modify it by prepending or > appending package-specific directories. These considerations really > apply to all shell scripts. > > Note the last sentence ;) > > Yes, people do put the full path in their scripts, which makes them > brittle and unfortunate. Why do people put the full path in their > scripts? Often it's because the tools they want to use aren't shipped > already in the $PATH. For example, the useful tools in bind9utils. > > So actually fixing this bug would lead to less brittle systems in the > future, which is a good thing. > > > Nothing prevents you from calling these programs with the full path (or > > changing PATH in your script). > > If we want to continue supporting things that have embedded the full > path, we can ship symlinks in /usr/sbin/ that point back to /usr/bin. > > If we shipped these backward-compatibility symlinks, would that be > acceptable to address your concerns? > > --dkg > _______________________________________________ > pkg-dns-devel mailing list > pkg-dns-de...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg-dns-devel > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)