Date: Sun, 9 Oct 2005 05:02:55 -0400 (EDT) From: Trevor Johnson <trevor@jpj.net> To: Hiroki Sato <hrs@FreeBSD.org> Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/print/acroread7 Makefile Message-ID: <20051009035347.D23871@blues.jpj.net> In-Reply-To: <20051009.051242.25152981.hrs@allbsd.org> References: <200510052317.j95NHWBa083203@repoman.freebsd.org> <20051009.051242.25152981.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiroki Sato wrote: > Trevor Johnson <trevor@FreeBSD.org> wrote > in <200510052317.j95NHWBa083203@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051009035347.D23871>