Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)

["Đoàn Trần Công Danh" <congdanhqx@gmail.com>]

On 2022-07-22 06:23:05-0700, David Chmelik <dchmelik@gmail.com> wrote:
> On 7/17/22 4:06 AM, Beat Bolli wrote:
> > On Fri, Jul 15, 2022 at 03:35:49AM -0700, David Chmelik wrote:
> > > What did you do before the bug happened?
> > > 'git clone,' built various software (with gcc, BSD & GNU make, autotools,
> > > cmake, etc.)
> > > 
> > > What did you expect to happen?
> > > Option: keep cloned/built/etc. files user-writable.
> > > 
> > > What happened instead?
> > > Needed chmod or 'sudo rm -rf.'
> > > 
> > > What's different between what you expected and what actually happened?
> > > Option: keep cloned/built/etc. files user-writable, otherwise (has been said
> > > 15+ years) encourages 'sudo rm -rf.'
> > > 
> > > Anything else you want to add:
> > >          I try/test/debug (and report bugs) many software commits but don't
> > > commit so need cloned/built/etc. files writable as user & even system-wide
> > > options: who hasn't made 'rm -rf' mistakes? (unrelated but someone might
> > > claim is: I don't use non-UNIX-like OS that shell alias 'rm -rf' to confirm
> > > every file (potentially thousands) and though made my own alias (confirm
> > > once) it's longer, sometimes unavailable so don't always use (many people
> > > don't)... software should always have user-writable files option.)  Below
> > > indicates GNU/Linux but also have often used git on *BSD/Unix.  I'm not on
> > > git mailing list but you can CC me all replies.
> > When building software as the current user, the build artefacts are
> > owned by this user.
> Ownership, permissions are different: one can own files yet have zero
> permission to write/delete and be denied that.  After cloning, archiving,
> building most/all projects I tried from (hundreds/thousands) git commits I
> typically/always had zero permission to write/delete some files/directories
> within--despite owning--which led to more steps to delete and temptation to
> sudo 'rm -rf' (or preferably alias or script such as 'rm -RfI' (FreeBSD
> UNIX) or 'rm -rf --interactive=once' (GNU) but may not always be available).
> 
> > Are you building the software using Docker containers that run as root?
> I don't use containers.  I noticed some projects' cmake & 'sudo make
> install' put root-owned files in build directory but doesn't seem to happen

cmake & sudo make install

is your problem

cmake only generate a build system for your project.
After that, you need to run make to build its artifarts before running
(sudo) make install.

If you don't run `make` first, `make install` will trigger `make all`
implicitly, since `install` target depends on `all` target.
Thus, `sudo make install` will invoke some sort of equivalence of
`sudo make`, thus all build output will be owned by root.

So, there're nothing to do with git.


> with other build systems--especially not plain make (BSD nor GNU nor with
> autotools)--still-used by almost all projects I try commits from.
>         So, I don't think root is the problem; IIRC usually problem was
> cloned directories had one or more subdirectories (such as .git* or
> files/subdirectories further in those) that were/became user non-writeable
> so I ended up writing a bash function (on SlackWiki.com &
> docs.Slackware.com) to make git clones user-writable: should be by default
> (before & after building in .git*, etc.) and/or a well-documented
> beginner/easy option (is it even an option?) because surely many more people
> only test than commit.  Instructions say 'git clone URL' assuming someone
> will commit rather than only test and want to avoid user-non-writeable files
> (I doubt I even need .git* subdirectories until ever start committing (don't
> plan to: I only like decimal-numbered tarballs made manually rather than
> version control) so would rather opt-out).  I don't recall commits from
> three other/older major version control systems be(com)ing user
> non-writeable (though all less-used apart from on classic UNIX/*BSD I don't
> use much anymore besides servers but wish had more hardware support to be
> more desktop-useable).

-- 
Danh