[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: copyright problem with install-sh, request for clean-room rewrite

From: Eric Blake
Subject: Re: copyright problem with install-sh, request for clean-room rewrite
Date: Mon, 3 Sep 2018 15:41:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 09/03/2018 01:24 PM, Paul Eggert wrote:
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.

Thanks for volunteering.

Indeed, and I think you are reasonably safe for the task.

Eric, do you think it would save time overall if you sent him the part of install-sh that you are sure is *not* problematic, i.e., the part that is already copyright by the FSF? That's typical procedure in a cleanroom rewrite of anything large; dunno if it's overkill here.

One thing that is for certain copyright by the FSF is the fact that 'install-sh --help' outputs a useful summary (as the original install-sh merely reports "install: --help does not exist"). So here's a nice starting point:

$ lib/install-sh --help
Usage: lib/install-sh [OPTION]... [-T] SRCFILE DSTFILE
   or: lib/install-sh [OPTION]... SRCFILES... DIRECTORY
   or: lib/install-sh [OPTION]... -t DIRECTORY SRCFILES...
   or: lib/install-sh [OPTION]... -d DIRECTORIES...

In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.

     --help     display this help and exit.
     --version  display version info and exit.

  -c            (ignored)
-C install only if different (preserve the last data modification time)
  -d            create directories instead of installing files.
  -g GROUP      chgrp installed files to GROUP.
  -m MODE       chmod installed files to MODE.
  -o USER       chown installed files to USER.
  -s            strip installed files.
  -t DIRECTORY  install into DIRECTORY.
  -T            report an error if DSTFILE is a directory.

Environment variables override the default commands:

Other black-box testing that I can readily describe is based on how automake uses the script (as those are the command line invocations that must work; it may be easier to start with a rewritten script that is less full-featured than what the current one does, as long as it provides everything that automake actually uses it for):

install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
mkinstalldirs = $(install_sh) -d
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
        -test -n "$(am__skip_mode_fix)" \
        || find "$(distdir)" -type d ! -perm -755 \
                -exec chmod u+rwx,go+rx {} \; -o \
          ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
          ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
          ! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
        || chmod -R a+r "$(distdir)"

        if test -z '$(STRIP)'; then \
              install; \
        else \
            "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \

Comparing to GNU coreutils, which also ignores -c, I have no idea why Automake's snippets that use $(install_sh) pass -c; and while I see a definite use of -d, -m, -s, and $STRIPPROG, I don't see an obvious use of -g, -o, -C, or some of the other environment variables, at least for what automake itself expects to exist (although it's harder to predict what functionality other projects have come to rely on in their usage of install-sh).

I also note that 'lib/mkinstalldirs' has a different copyright/license (namely, "Public domain"), where I don't know if we need to rewrite that one as well; and find it odd that we also have a line in generated Makefiles that uses 'install-sh -d' in place of mkinstalldirs. It may make sense to have automake quit shipping mkinstalldirs, and merely rely on $(MKDIR_P) and/or 'install-sh -d', for one less helper script installed by automake.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization: |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]