Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Philip Hands writes: > I stumbled across 'proot' while looking into the background for this, > which seems to be able to provide the effect of a bind mount without > needing root privilege, and would presumably deal with Ian's original > problem quite nicely. If you enable unprivileged user

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Fri, Jan 13, 2017 at 10:04:34AM -0500, Sam Hartman wrote: > > "Josh" == Josh Triplett writes: > > Josh> As another technical alternative, which I haven't seen > Josh> mentioned elsewhere in this thread or related bug reports: > Josh> when I need to

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Sam Hartman writes: >> "Josh" == Josh Triplett writes: > > Josh> As another technical alternative, which I haven't seen > Josh> mentioned elsewhere in this thread or related bug reports: > Josh> when I need to override a packaged

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

> "Josh" == Josh Triplett writes: Josh> As another technical alternative, which I haven't seen Josh> mentioned elsewhere in this thread or related bug reports: Josh> when I need to override a packaged binary or file temporarily Josh> for debugging

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 1 more messages]

Josh Triplett writes ("Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"): > I find it surprising that this has ended up in front of the Technical > Committee before it has, for instance, ended up on debian-policy or > debian-devel for discus

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Wed, 11 Jan 2017 14:59:06 -0500 Sam Hartman wrote: > I'll note that the practice of hard-coding paths is fairly common. > > > One common cause for this is programs that don't want to rely on PATH > for calling exec. Systemd is a particularly interesting example. >

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Wed, 11 Jan 2017 13:51:27 -0500 Daniel Kahn Gillmor wrote: > Please do not do this to gpg-agent unless upstream is fine with this > change. I have more important things i want to consider divergence from > upstream about, and i don't think this particular scenario is a

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Nikolaus Rath wrote: >>> Policy 6.1 says >>> | Programs called from maintainer scripts should not normally have a >>> | path prepended to them. >>> >>> Ie, programs that are on PATH should be found via the PATH rather than >>> by hardcoding /usr/bin/foo or whatever. In general, I think we >>>

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

>> Policy 6.1 says >> | Programs called from maintainer scripts should not normally have a >> | path prepended to them. >> >> Ie, programs that are on PATH should be found via the PATH rather than >> by hardcoding /usr/bin/foo or whatever. In general, I think we >> normally, at least in software

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts [and 2 more messages]

s not compatible with other versions of its callers. But of course such a thing probably wouldn't be on PATH at all.) Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"): > I'll note that the practice of hard-coding paths is fa

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Dear Ian, while I see where you come from, and can empathize with some of your points, I think that Daniel's following of upstream practices in using full paths is both fairly common, and a valid practice in Debian Packages. Le mercredi, 11 janvier 2017, 17.13:44 h CET Ian Jackson a écrit : >

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Sam Hartman writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"): > [some stuff] Please concentrate on the MIPS binutils bug. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

]] Sam Hartman > So, I'd be much more comfortable if we wanted to help make people more > aware of the tradeoffs than I would setting policy. Overall, I agree with Sam here, it's hard to come up with hard rules about this, and as long as upstream and the Debian maintainer have thought properly

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

I'll note that the practice of hard-coding paths is fairly common. One common cause for this is programs that don't want to rely on PATH for calling exec. Systemd is a particularly interesting example. ExecStart and related arguments in systemd units are required to include full paths. I am

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts"): > Ian, in the future please x-debbugs-cc me when you take our discussions > to the tech-ctte :) Sorry, I should have thought of that. Thanks for your reply. There

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Hi Ian (and hi tech-ctte!)-- On Wed 2017-01-11 12:13:44 -0500, Ian Jackson wrote: > Package: tech-ctte > Control: block 850657 by -1 Ian, in the future please x-debbugs-cc me when you take our discussions to the tech-ctte :) > Policy 6.1 says > | Programs

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Package: tech-ctte Control: block 850657 by -1 Policy 6.1 says | Programs called from maintainer scripts should not normally have a | path prepended to them. Ie, programs that are on PATH should be found via the PATH rather than by hardcoding /usr/bin/foo or whatever. In general, I think we