Problems installing as root

Problems installing as root

[walt]

I'm current as of this morning (7bd59dee...) and I'm still seeing
two problems with doing 'make' as myself but 'make install' as
root.

First, 'make install' as root leaves dozens of files owned by root
in my personal source directory.  A minor nit, but inconvenient
during the next 'make'.

Second, this is a more recent problem with 'make install':
make -C git-gui all
make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
GITGUI_VERSION = 0.6.GITGUI
make[1]: Leaving directory `/usr/local/mnt/wa1ter/src/git/git-gui'
make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
/bin/sh ./CREDITS-GEN
error: Cannot locate authorship information.
make[1]: *** [CREDITS-FILE] Error 1

Now, CREDITS-FILE was generated during 'make' (I checked) so there
was no need to generate it again during 'make install', yes?

Thanks!

Re: Problems installing as root

[Shawn O. Pearce]

walt <wa1ter@myrealbox.com> wrote:
> I'm current as of this morning (7bd59dee...) and I'm still seeing
> two problems with doing 'make' as myself but 'make install' as
> root.
> 
> First, 'make install' as root leaves dozens of files owned by root
> in my personal source directory.  A minor nit, but inconvenient
> during the next 'make'.

Which files, specifically?  I'm sure that the following would be
built as root during 'make install':

  GIT-CFLAGS
  GIT-VERSION-FILE
  git-gui/GIT-VERSION-FILE
  git-gui/CREDITS-FILE

as these are rebuilt automatically everytime the Makefile runs,
as they are embedding version data from HEAD.  But others would be
interesting to know about.
 
> Second, this is a more recent problem with 'make install':
> make -C git-gui all
> make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
> GITGUI_VERSION = 0.6.GITGUI

Hmm.  You can't get the right version number for git-gui.  Do you
have tags fetched?

In order to build completely from source git-gui needs its gitgui-*
tags in refs/tags.  Junio pushed the gitgui-0.6.1 tag when he merged
that version into `maint`.

> make[1]: Leaving directory `/usr/local/mnt/wa1ter/src/git/git-gui'
> make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
> /bin/sh ./CREDITS-GEN
> error: Cannot locate authorship information.
> make[1]: *** [CREDITS-FILE] Error 1

Same error as above.  Only this time it made the build stop, rather
than assuming some default version (0.6.GITGUI).
 
> Now, CREDITS-FILE was generated during 'make' (I checked) so there
> was no need to generate it again during 'make install', yes?

Odd.  We created the CREDITS-FILE during `make` but then barfed
during `make install` by acting like we cannot locate the gitgui tag?

What does `git tag -l | grep gitgui-` give you when run as root?


As a workaround you may be able to copy `git-gui/CREDITS-FILE` to
`git-gui/credits`, then run `make install`.  CREDITS-GEN defaults
to the credits file, as that is shipped in the tarfile.

-- 
Shawn.

Re: Problems installing as root

[Junio C Hamano]

walt <wa1ter@myrealbox.com> writes:

> I'm current as of this morning (7bd59dee...) and I'm still seeing
> two problems with doing 'make' as myself but 'make install' as
> root.
>
> First, 'make install' as root leaves dozens of files owned by root
> in my personal source directory.  A minor nit, but inconvenient
> during the next 'make'.
> ...
> Second, this is a more recent problem with 'make install':

Does 'make all' followed by 'make install' do the same?  If so
these are indeed very bad.

If you run 'make all', and then if you run, without changing
anything to cause rebuilding, run 'make install', the build
procedure should not create _any_ new file.  Otherwise the build
procedure is broken and needs to be fixed.

Re: Problems installing as root

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Which files, specifically?  I'm sure that the following would be
> built as root during 'make install':
>
>   GIT-CFLAGS
>   GIT-VERSION-FILE
>   git-gui/GIT-VERSION-FILE
>   git-gui/CREDITS-FILE
>
> as these are rebuilt automatically everytime the Makefile runs,
> as they are embedding version data from HEAD.

We should strive to make sure that "find -type f -newer .stamp"
after "make all; date >.stamp; sleep 2; make all" reports
nothing.  Otherwise we would break:

	$ make all
        $ su
        # make install

How about doing something like this (you would need -p2 to apply
to your tree)?

diff --git a/git-gui/CREDITS-GEN b/git-gui/CREDITS-GEN
index da2c076..d1b0f86 100755
--- a/git-gui/CREDITS-GEN
+++ b/git-gui/CREDITS-GEN
@@ -20,8 +20,8 @@ tree_search ()
 generate_credits ()
 {
 	tip=$1 &&
-	rm -f $CF &&
-	git shortlog -n -s $tip | sed 's/: .*$//' >$CF || exit
+	rm -f "$2" &&
+	git shortlog -n -s $tip | sed 's/: .*$//' >"$2" || exit
 }
 
 # Always use the tarball credits file if found, just
@@ -36,10 +36,14 @@ generate_credits ()
 # that fact.
 #
 
+credits_tmp=/var/tmp/gitgui-credits-$$
+trap 'rm -f "$credits_tmp"' 0
+
+orig="$credits_tmp"
+
 if test -f credits
 then
-	rm -f $CF &&
-	cp credits $CF || exit
+	orig=credits
 elif prefix="$(git rev-parse --show-prefix 2>/dev/null)" &&
    test -n "$prefix" &&
    head=$(git rev-list --max-count=1 HEAD -- . 2>/dev/null) &&
@@ -47,12 +51,21 @@ elif prefix="$(git rev-parse --show-prefix 2>/dev/null)" &&
    tip=$(tree_search $head $tree) &&
    test -n "$tip"
 then
-	generate_credits $tip || exit
+	generate_credits $tip "$orig" || exit
 elif tip="$(git rev-parse --verify HEAD 2>/dev/null)" &&
    test -n "$tip"
 then
-	generate_credits $tip || exit
+	generate_credits $tip "$orig" || exit
 else
 	echo "error: Cannot locate authorship information." >&2
 	exit 1
 fi
+
+if test -f "$orig" && cmp -s "$orig" "$CF"
+then
+	: noop
+else
+	rm -f "$CF" &&
+	cat "$orig" >"$CF"
+fi
+

Re: Problems installing as root

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> How about doing something like this (you would need -p2 to apply
> to your tree)?
> 
> diff --git a/git-gui/CREDITS-GEN b/git-gui/CREDITS-GEN

No dice:

	$ git apply -p2 e
	error: git-gui/CREDITS-GEN: Not a directory

	$ git version
	git version 1.5.0.1.641.g3d8a

Anyway - I'm applying that now (hand editing the patch), and will
do the same in GIT-VERSION-GEN for git-gui.

What about the top level GIT-VERSION-GEN in git.git?

-- 
Shawn.

Re: Problems installing as root

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> ..., and will
> do the same in GIT-VERSION-GEN for git-gui.

I had an impression that GIT-VERSION-GEN in git-gui was Ok.

> What about the top level GIT-VERSION-GEN in git.git?

I thought it is much more careful than git-gui/CREDITS-GEN about
avoiding unnecessary rebuilding.

Re: Problems installing as root

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > ..., and will
> > do the same in GIT-VERSION-GEN for git-gui.
> 
> I had an impression that GIT-VERSION-GEN in git-gui was Ok.

It is.  I just looked at it to see about fixing it too and just
realized what the `test $VN = $VC ||` chunk was all about.  :-)

> > What about the top level GIT-VERSION-GEN in git.git?
> 
> I thought it is much more careful than git-gui/CREDITS-GEN about
> avoiding unnecessary rebuilding.

Yes, it is.  I didn't realize what it was doing until just now.  :-)


Apparently I'm missing the obvious tonight.  There is a new version
of git-gui now pushed out (1 commit, your patch).  I did not bother
to tag it.   Please pull into maint.

-- 
Shawn.

Re: Problems installing as root

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> ... There is a new version
> of git-gui now pushed out (1 commit, your patch).  I did not bother
> to tag it.   Please pull into maint.

Thanks, will do.

Re: Problems installing as root

[walt]

Shawn O. Pearce wrote:
> walt <wa1ter@myrealbox.com> wrote:
>> First, 'make install' as root leaves dozens of files owned by root
>> in my personal source directory.

> Which files, specifically? ...

~/src/git $find . -user 0
./git-fsck-objects
./git-archive
./git-cherry
./git-whatchanged
./git-annotate
./git-status
./git-merge-octopus
./git-show
./git-update-index
./git-format-patch
./git-quiltimport
./git-verify-pack
./git-rev-list
./git-cvsserver
./git-runstatus
./git-pull
./git-merge-file
./git-log
./git-repack
./git-mailinfo
./git-rm
./git-applypatch
./git-parse-remote
./git-reset
./git-mailsplit
./git-for-each-ref
./git-svnimport
./git-grep
./git-write-tree
./git-ls-files
./git-add--interactive
./git-verify-tag
./git-prune
./git-diff
./git-rebase
./git-branch
./git-check-ref-format
./git-push
./git-cat-file
./git-prune-packed
./git-merge-stupid
./git-mv
./git-merge-ours
./git-add
./git-name-rev
./git-merge-base
./git-read-tree
./git-commit-tree
./git-ls-remote
./git-tag
./git-init
./git-init-db
./git-rev-parse
./git-pack-refs
./git
./git-show-branch
./git-commit
./git-get-tar-commit-id
./git-fsck
./git-reflog
./git-applymbox
./git-merge
./git-cherry-pick
./git-diff-files
./git-fetch
./git-fmt-merge-msg
./git-blame
./git-tar-tree
./git-request-pull
./git-archimport
./git-count-objects
./git-cvsexportcommit
./git-show-ref
./git-shortlog
./git-merge-resolve
./git-checkout-index
./git-gc
./git-am
./git-diff-index
./git-revert
./git-clean
./git-stripspace
./git-ls-tree
./git-unpack-objects
./git-checkout
./git-pack-objects
./git-merge-one-file
./git-lost-found
./git-svn
./git-remote
./git-update-ref
./git-apply
./git-repo-config
./git-symbolic-ref
./git-diff-tree
./git-upload-archive
./git-sh-setup
./git-send-email
./git-rerere
./git-config
./git-relink
./git-clone
./git-describe
./git-bisect
./git-cvsimport

>> Second, this is a more recent problem with 'make install':
>> make -C git-gui all
>> make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
>> GITGUI_VERSION = 0.6.GITGUI

> Hmm.  You can't get the right version number for git-gui.  Do you
> have tags fetched?

Oops.  I stupidly forgot to tell you the reason for the failure
when running the script as root:  /usr/local is not in root's path,
and thus /usr/local/bin/git-* can't be found.  Since the script
assumes that git is already installed and working, I would guess
that it would also fail if I had just fetched Junio's repository
for the first time and attempted an initial install.

Sorry for that important omission :o(

Re: Problems installing as root

[walt]

Junio C Hamano wrote:
> walt <wa1ter@myrealbox.com> writes:

>> 'make install' as root leaves dozens of files owned by root
>> in my personal source directory...

> Does 'make all' followed by 'make install' do the same?  If so
> these are indeed very bad.
> 
> If you run 'make all', and then if you run, without changing
> anything to cause rebuilding, run 'make install', the build
> procedure should not create _any_ new file.  Otherwise the build
> procedure is broken and needs to be fixed.

'make all' does exactly the same thing.  (The Makefile says that
'make all' is the default target, so it should behave the same,
no?)

Thanks.

Re: Problems installing as root

[Shawn O. Pearce]

walt <wa1ter@myrealbox.com> wrote:
> Shawn O. Pearce wrote:
> > walt <wa1ter@myrealbox.com> wrote:
> >> First, 'make install' as root leaves dozens of files owned by root
> >> in my personal source directory.
> 
> > Which files, specifically? ...
> 
> ~/src/git $find . -user 0
> ./git-fsck-objects
...+100 files...

This is caused by below...

> >> Second, this is a more recent problem with 'make install':
> >> make -C git-gui all
> >> make[1]: Entering directory `/usr/local/mnt/wa1ter/src/git/git-gui'
> >> GITGUI_VERSION = 0.6.GITGUI
> 
> > Hmm.  You can't get the right version number for git-gui.  Do you
> > have tags fetched?
> 
> Oops.  I stupidly forgot to tell you the reason for the failure
> when running the script as root:  /usr/local is not in root's path,
> and thus /usr/local/bin/git-* can't be found.  Since the script
> assumes that git is already installed and working, I would guess
> that it would also fail if I had just fetched Junio's repository
> for the first time and attempted an initial install.

Right.  So what is happening is the toplevel Makefile tries to run
GIT-VERSION-GEN to obtain the version, that calls git-describe,
which does not exist, fails, and falls back on the hardcoded version
number.  That version number differs from what the software was
compiled with, so it gets recompiled.  Instant set of +100 files
owned by root.

Same issue happens down inside of git-gui.

I think the only answer I have for you is the following:

  If you want to run the Makefile without having git in your path
  then make a tarball first (make dist) with Git in your path,
  then unpack the tarball and compile that.

  This works as the tarball embeds version and credits files that
  sidestep the need for git-describe.

-- 
Shawn.