[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :
> I would like the TC to:
>  * Declare that Debian policy should be clarified to say that programs
>    in Debian (not just maintainer scripts) should not hardcode the
>    location of the binaries in /{usr/,}{bin,sbin} they execute.

Asking the TC to declare the above seems _very_ premature to me. In 
particular, in the frame of §6.3.6, I don't think enough efforts have been put 
in resolving this via consensus. Rather, I think it _is_ a resolved issue 
(over the course of years), but that you happen to disagree with the 

>  * Say that this applies even when the program needs to find pieces of
>    the same (or closely related) package.

Reading this literally (which is what the Debian Policy is for), this would 
ask the Debian project to patch literally all its archive. For instance, that 
covers literally all shebang lines.

>  * Provide an informal opinion that this policy ought to apply to
>    gpg-agent as requested in #850657.

I went and read #850657, and found myself agreeing with all points made by 
Daniel: if you want a gnupg that runs your custom gpg-agent for debugging 
purposes, building a patched src:gnupg is there for you; we provide source for 
a reason.

All-in-all, I think that the decisions you would like the TC to issue would be 
against the project's consensus, and (which is more important for TC 
decisions) wouldn't be technically sound.

I'd be in favour of closing this bug above Further Discussion.


P.S. No need to reply asking me to focus on a different issue…

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: