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#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

I heard back from doko today. We can expect a reply tomorrow. We also talked briefly about the issue. Realistically, i cannot imagine the TC coming to any final decision on something like this in under three weeks. That timeline seems fairly aggressive actually. However, I think the TC could

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]

I see that I am Wrong On The Internet and my efforts not to distract the TC have been futile. Sorry. Now I am falling subject to the same problem but I really cannot let all of this go unchallenged. Daniel Kahn Gillmor writes ("Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded even

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 These opinions are my own. If I emailed you from an address

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 are some things

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#850887: Decide proper solution for binutils' mips* bug

On Tue, Jan 10, 2017 at 16:56:05 -0500, Sam Hartman wrote: > > Hi. > I'd really appreciate comments from debian-release on this issue. > Would debian-release like us to take this up? > If so, I have a proposal for how to fast-track this situation, but I am > only comfortable doing that if the

Bug#850887: TC Involvement: MIPS and binutils

On miércoles, 11 de enero de 2017 10:35:37 ART Sam Hartman wrote: [snip] > that was to doko not you. Usual me I'm afraid. I suscribed to the bug and forgot to see the To field. > I'd be happy to chat, but you've articulated your position fairly well. > If there's stuff not in the bug you'd like

Processed: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

Processing control commands: > block 850657 by -1 Bug #850657 [gnupg] gnupg: Please find gpg-agent on PATH 850657 was not blocked by any bugs. 850657 was not blocking any bugs. Added blocking bug(s) of 850657: 850967 -- 850657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850657 850967:

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

Bug#850887: TC Involvement: MIPS and binutils

> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer > writes: Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote: >> Hi. >> >> As you are probably aware, the question of what to do about >> linking on mips and stretch

Bug#850887: TC Involvement: MIPS and binutils

On miércoles, 11 de enero de 2017 11:49:48 ART Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > I'll be online from 17:30 UTC onwards, nick lisandro on freenode. And also oftc, of course. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/

Bug#850887: TC Involvement: MIPS and binutils

On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote: > Hi. > > As you are probably aware, the question of what to do about linking on > mips and stretch has been referred to the TC. > There's a reasonable probability that we're going to want to move very > quickly on this issue, and

Bug#850887: TC Involvement: MIPS and binutils

Hi. As you are probably aware, the question of what to do about linking on mips and stretch has been referred to the TC. There's a reasonable probability that we're going to want to move very quickly on this issue, and I wanted to reach out to you and see how we could best work with you to

Bug#850887: Decide proper solution for binutils' mips* bug

I would like to mention that in my previous mail I forgot another possible fix for this bug: going back to binutils 2.27. The current uploads are snapshots of the next version, 2.28, and whereas the bug in question seems to habe been there all the time it started to affect us since a commit in