On 2022-07-22 06:23:05-0700, David Chmelik <dchmelik@xxxxxxxxx> 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
