On 2026/09/24 20:27, Larry Moore wrote:
> > these are all going to be a total pain to deal with if upstream changes
> > anything in the install targets.
> >
> > is it actually useful to change these from user=rw to user=r as you're
> > doing?
> >
>
> Simple approach, if the files will not be changing, they don't require
> 'write' permission.
agreed, but patching a bunch of lines in an upstream Makefile often
results in a bunch of extra work to merge conflicts for any changes when
the port is updated to a new version, and past experience shows that
it's tedious error-prone work.
> > for the files in /usr/local/{bin,sbin} which are owned by root:bin
> > there's no issue with 755 anyway, that's very common in ports.
> >
>
>
> For the same reason as above. It's been decades since I had to hex-edit a
> binary file just to change the default behaviour of a program - not the best
> approach for an executable, and it was only on a once-off.
it doesn't change anything practical though, the files are root-owned,
and root can write to them anyway regardless of permissions.
> Also, excluding write permissions on an executable does not impact package
> upgrades.
>
> > for the files in /usr/local/libdata/hylafax which are owned by _hylafax,
> > I don't think it's really helping to make them r instead of rw because
> > the dir is writable anyway.
> >
>
> As above.
an alternative approach that would be simpler for updates would be to
chmod in post-install. I'm not aware of other ports doing this though,
and the vast majority of files in /usr/local/{bin,sbin} etc are mode
755 and owned by root.
