cvs commit: ports/print/acroread7 Makefile

[Trevor Johnson]

Hiroki Sato wrote:

> Trevor Johnson <trevor at FreeBSD.org> wrote
>   in <200510052317.j95NHWBa083203 at repoman.freebsd.org>:
>
> tr>   The license for the Adobe Reader forbids any changes to the installed
> tr>   files, even inserting the word "FreeBSD" into the wrapper script.
> tr>   By cleverly spoofing "uname" output we can avoid patching that
> tr>   script.
> tr>   Submitted by:   hrs
>
>  The license also forbids to create a new installer (according to
>  2.5 No Modification).  So, if print/acroread7 installs the
>  files by itself, not by the provided installer, it violates the term.
>  The Makefile now processes the RPM file with rpm2cpio(1) and installs
>  them with cpio(1).  I think this is a kind of installer.

In short, it seems to me that Adobe doesn't provide an installer which
installs the RPM packages, so this restriction does not apply to the RPM
packages.

Of course most Linux users would use the rpm utility that comes with their
distribution, when installing an RPM package.  However, the rpm utility is
shipped with rpm2cpio and cpio is also available on, I would assume, most
Linux distributions.  I don't see anywhere where Adobe is specifically
telling us that we must use the rpm utility rather than rpm2cpio and cpio
to unpack the RPM packages.  Certainly Adobe doesn't provide its
own version of the rpm utility.

Now, RPM packages may contain a script which is automatically run by the
rpm urility upon installation.  Correct me if I'm wrong, but I didn't
notice that the Adobe Reader RPMs contain such scripts.  If they do then
you could argue that by not running the script (which, when extracting
with rpm2cpio piped to cpio, we don't), we're avoiding the use of their
"installer" and hence "creating a new installer."  Instead of arguing the
opposite, I would be willing to go back to using the rpm command to
extract the files.

>  I have sent a patch to use a tarball instead of an RPM package
>  to avoid this problem.  Whether the current print/acroread7/Makefile
>  is "an installer" or not remains a matter of debate, but
>  the tarball includes "INSTALL" script explicitly and we can think
>  the Makefile as "an wrapper for the provided installer" by using it.
>  So, this method is safer from the aspect of license compliance IMO,
>  and also we can remove a dependency on archivers/rpm.

As you say, the tarball explicitly includes a script called "INSTALL." The
restriction about not making a new installer would apply to the tarball.
This leads me to the opposite conclusion:  that the RPM is, as you put it,
safer from the aspect of license compliance.

>  Do you have any specific reasons to use the RPM package?

In the commentary you sent me with your patch, the only remark you made
about this subject was "Use .tar.gz distfile instead of .rpm."  The notion
that by using RPMs we might be creating our own installer, or that by
using the tarballs we could avoid this, didn't cross my mind.  I just
assumed that it was intended to avoid the dependency on the rpm command.
My thinking was along the lines of, this port depends on linux_base and
most of the linux_base ports depend (when installed from ports rather than
packages) on the rpm command so users have it already, and changing to the
tar package will mean that users have to download a big tar file if
there's a PORTREVISION bump before the next Adobe Reader version comes
out.

Apart from the question about whether the RPMs contain an installation
script that we must run, the dependency on rpm2cpio from
ports/archivers/rpm could be avoided by using the Perl workalike from
ports/archivers/rpm2cpio.  For awhile these were in conflict, both
installing a command rpm2cpio.  Thus a port could depend on that rpm2cpio
command and if a user had either of those two ports (archivers/rpm or
archivers/rpm2cpio) already installed, they wouldn't get extra stuff
installed on their system.  Now the conflict has been fixed by making
archivers/rpm2cpio install as rpm2cpio.pl so depending on it raises the
spectre of forcing users to install Perl (ugh!).
-- 
Trevor Johnson