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 namesp
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 override a packaged binary or
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 binary or file temporarily
> Josh> for debuggi
> "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 purposes, without forgetting
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
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.
> ExecStart and related argum
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 healthy
> use of debian
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
>>> nor
>> 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 w
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 fairly common.
It is a common bug.
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 :
> I
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 JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.
]] 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 t
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 ver
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
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 called from maintainer scripts should
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
norm
17 matches
Mail list logo