Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)
- From
- David Chmelik <dchmelik@gmail.com>
- Date
- Jul 22, 2022, 13:23 UTC
- Message-ID
- <158251f2-9fa4-45b7-4c24-907c94602b6e@gmail.com>
- In-Reply-To
- <YtPtQ6qsIviyTBF2@zbox.drbeat.li>
On 7/17/22 4:06 AM, Beat Bolli wrote:
Show 27 quoted lines
> 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 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).