Subject: Re: [boost] Executable files in Boost git repostories
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-12-04 00:40:17
On 2018-12-03 19:31, Gavin Lambert via Boost wrote:
> On 4/12/2018 13:24, Edward Diener wrote:
>> We have again run into the situation where files with a Linux
>> executable permission have been committed to various Boost git
>> repositories, with Jim King creating a PR and list of these files in
>> Boost Admin. I have fixed these for the repositories for which I have
>> write access, and created PRs for the other repositories. But this
>> begs the question as to what Boost's stance should be about adding
>> actual executable files to a Boost git repository ? As an example a
>> Linux bash command file was added to a particular repository and I
>> created a PR to remove the executable file permission from the file.
>> But the maintainer of the repository feels this is wrong and the
>> Linux bash file should retain the executable file permissions and
>> that the file should be part of the repository. But of course I am
>> more interested here about the general principal of the matter.
>> Obviously operating system command/batch files are executable files,
>> but should they be so in a repository.
> Files which are not actually executable scripts should not have that
> bit set, of course.
> Files which are executable scripts generally should have the bit set,
> even in the repository.
> However then the question becomes: are these scripts only for the
> maintainer's use (in which case perhaps they shouldn't be in the
> repository?) or are they intended for user use (in which case what
> happens on platforms that cannot run the script?)
> So for portability reasons, in my opinion, it's probably better to get
> b2 to do things rather than writing custom scripts that don't work on
> all platforms.
Why do we even have to discuss this here globally, rather than trusting
project maintainers to know what they are doing ?
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk