Bug 90319 - [PATCH], change print/acroread7 to use tarball rather than rpm.
Summary: [PATCH], change print/acroread7 to use tarball rather than rpm.
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Jeremy Messenger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-13 05:40 UTC by Jeremy Messenger
Modified: 2006-02-25 16:46 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Messenger freebsd_committer 2005-12-13 05:40:02 UTC
   1) ${PREFIX}/lib/acroread/usr/local/Adobe[...] is not right, which
      there has double main directory (ie: /usr/local[...]/usr/local) and
      is too long. The RPM's original location is /usr/Adobe/Acrobat7.0[...].
      The best method is to use the tarball instead RPM that has a
      installer.

   2) Since, you love to follow the license, so I had to input in here. I
      believe that your method of using RPM has violated the license,
      because your method is called a new installer by extract from RPM
      then install by your Makefile. In the license (LICREAD.TXT) said:

      ==========================================
      2.5 No Modification. You may customize or extend the functionality
      of the installer for the Software as specifically allowed by
      instructions found at http://www.adobe.com/support/main.html or
      http://partners.adobe.com (e.g., installation of additional plug-in
      and help files). You may not otherwise alter or modify the Software
      or create a new installer for the Software. [...goes on...]
      ==========================================

      japanese/acroread's method is using tarball that doesn't violate the
      license by using Adobe's installer without any of modify and use its
      functions/options for prefix and etc. I copied from
      japanese/acroread/Makefile to acroread7/Makefile with a few modify
      such as install in ${PREFIX}/Adobe/Acrobat7.0 and other stuff that
      is very close to same default as in the Adobe's installer.

      I removed the "Be sure to read the license agreement in" part,
      because the installer will required any of you to read the license
      and type 'accept' or 'decline' if you agree or not with it before
      you install it. Adobe will love us more for this.

   3) Change from bin/acroread7 to bin/acroread, because it broke the
      plugin and other third-party apps. The print/acroread (version 5)
      has been marked as FORBIDDEN and will be remove in Jan.

   4) Add symlink of plugin in lib/browser_linux_plugins.

   5) I am not going to be surprised if my patch will break other slave
      port (adobe language), so I don't mind to modify all of them. I
      personal would put CONFLICTS to the each others in those ports. It
      makes no sense for us to have two acroread7 installed at the same
      time, because of plugins and 'acroread' in the other third-party
      apps. If we put CONFLICTS then all other third-party apps will
      working with those acroread7 ports without any of modify.

      Any thought on this?

   6) Using static plist, the dynamic plist is not need to be in this
      port.

   7) I didn't add BRANDELF or remove the NO_FILTER_SHLIBS, because I am
      kind of confused from the Adobe's license. I am leaving that kind of
      stuff alone.

If there is any of my English grammar that is confusing you, please feel free
to tell me that you don't understand some parts in here. I will be happy to
try to make a better one.

Fix: 

Patch: http://people.freebsd.org/~mezz/diff/acroread7.diff
How-To-Repeat: n/a
Comment 1 Jeremy Messenger freebsd_committer 2005-12-13 05:41:48 UTC
Responsible Changed
From-To: freebsd-ports-bugs->trevor

To maintainer of acroread7
Comment 2 Alexander.LEIDINGER 2005-12-13 08:57:30 UTC
Hi,

all points look sensible, but I have some input for point 5. I assume you are talking about the ports which install acroread in different languages.

I think it's beneficial to be able to install multiple languages at once. At work (where I'm mailing this from) we don't use FreeBSD, but we have a multilingual environment here. If FreeBSD would be used here, we would have the need to install at least english, french and german versions.

I don't think this is a showstopper, but it can maybe solved with a wrapper which looks at LANG and runs the appropriate one if installed. The plugin problem can be solved with a plist variable. The port which installs the link is responsible for removing it. If this port is removed without removing other ports, we don't have the plugin anymore (unless one of the remaining ports is reinstalled), but we have at least defined behavior.

For me it's ok, if you go with your way (CONFLICTS), but I'm not the maintainer...

While I think that you can use brandelf, since it modifies the ELF header which is designed to allow this and thus is subject to "use as designed/intended", I suggest to add a comment explaining the issue if you don't want to use it for legal reasons.

Bye,
Alexander.

-- 
Alexander Leidinger
OPOCE, Bureau 487
00352 29 29 42 468
Comment 3 Jeremy Messenger 2005-12-13 18:30:42 UTC
On Tue, 13 Dec 2005 02:57:30 -0600, Alexander Leidinger  
<Alexander.LEIDINGER@opoce.cec.eu.int> wrote:

> Hi,
>
> all points look sensible, but I have some input for point 5. I assume  
> you are talking about the ports which install acroread in different  
> languages.

Yes, that's right. The slave ports is what I meant for acroread language.

> I think it's beneficial to be able to install multiple languages at  
> once. At work (where I'm mailing this from) we don't use FreeBSD, but we  
> have a multilingual environment here. If FreeBSD would be used here, we  
> would have the need to install at least english, french and german  
> versions.

I wish Adobe would provide the language package rather than a full package  
for each language. Anyway, we can't wish for everything so move on.... :-)

> I don't think this is a showstopper, but it can maybe solved with a  
> wrapper which looks at LANG and runs the appropriate one if installed.

Okay, it sounds like we need to create a 'acroreadwrapper' port that is  
for ${PREFIX}/bin/acroread and plugins in  
${PREFIX}/lib/browser_linux_plugins (no idea if it will working for  
plugins), then set all acroread7 and its language ports to depend on  
acroreadwrapper. Good idea? or another idea?

> The plugin problem can be solved with a plist variable. The port which  
> installs the link is responsible for removing it. If this port is  
> removed without removing other ports, we don't have the plugin anymore  
> (unless one of the remaining ports is reinstalled), but we have at least  
> defined behavior.

The plist is not part that I am worry about. It's just for plugins and  
third-party apps if they will working with the wrapper. The  
acroreadwrapper idea will taking care of plist stuff.

> For me it's ok, if you go with your way (CONFLICTS), but I'm not the  
> maintainer...

Well, I am lazy so I put idea of CONFLICTS. Shame on me. :-) I will trying  
to create acroreadwrapper and test those. I might need a help or not. If  
anyone want to beat it to me, please feel free to do it and let me know.

> While I think that you can use brandelf, since it modifies the ELF  
> header which is designed to allow this and thus is subject to "use as  
> designed/intended",

Exactly, it's what I am thinking of that "use as designed/intended" that I  
don't think there will be any issue with it as long we don't provide any  
of distribution package (as we already have RESTRICTED). Trevor, do you  
agree on this?

Cheers,
Mezz

> I suggest to add a comment explaining the issue if you don't want to use  
> it for legal reasons.
>
> Bye,
> Alexander.


-- 
mezz7@cox.net  -  mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome@FreeBSD.org
Comment 4 Alexander.LEIDINGER 2005-12-14 08:01:32 UTC
On Tue, 2005-12-13 at 19:30, Jeremy Messenger wrote:

> > I don't think this is a showstopper, but it can maybe solved with a  
> > wrapper which looks at LANG and runs the appropriate one if installed.
> 
> Okay, it sounds like we need to create a 'acroreadwrapper' port that is  
> for ${PREFIX}/bin/acroread and plugins in  
> ${PREFIX}/lib/browser_linux_plugins (no idea if it will working for  
> plugins), then set all acroread7 and its language ports to depend on  
> acroreadwrapper. Good idea? or another idea?

An extension to your idea: let the wrapper print a warning in case the plugin isn't linked to an existing one. Provide a script which can be called by root when the plugin isn't linked correctly but a good plugin exists.

Unfortunately we don't have variable/magic symlinks (as listed in the list for volunteers), else we could provide a link which points to the right language version of the plugin...

Bye,
Alexander.

-- 
Alexander Leidinger
OPOCE, Bureau 487
00352 29 29 42 468
Comment 5 Jeremy Messenger 2005-12-14 21:41:07 UTC
On Wed, 14 Dec 2005 02:01:32 -0600, Alexander Leidinger  
<Alexander.LEIDINGER@opoce.cec.eu.int> wrote:

> On Tue, 2005-12-13 at 19:30, Jeremy Messenger wrote:
>
>> > I don't think this is a showstopper, but it can maybe solved with a
>> > wrapper which looks at LANG and runs the appropriate one if installed.
>>
>> Okay, it sounds like we need to create a 'acroreadwrapper' port that is
>> for ${PREFIX}/bin/acroread and plugins in
>> ${PREFIX}/lib/browser_linux_plugins (no idea if it will working for
>> plugins), then set all acroread7 and its language ports to depend on
>> acroreadwrapper. Good idea? or another idea?
>
> An extension to your idea: let the wrapper print a warning in case the  
> plugin isn't linked to an existing one. Provide a script which can be  
> called by root when the plugin isn't linked correctly but a good plugin  
> exists.
>
> Unfortunately we don't have variable/magic symlinks (as listed in the  
> list for volunteers), else we could provide a link which points to the  
> right language version of the plugin...

I am wondering if a wrapper for plugins that is written in C by using  
dlopen() to find plugins's path then compile in Linux. Will it works? I  
don't know much about C, so had to ask if it will work. ;-)

Or another solution that I can think of is to teach each apps to  
understand where the plugins' path. I know that it's possible for  
linux-opera, but I never check for linux-firefox or other port. I won't be  
surpised if linux-firefox has shell script for bin directory like with our  
native Firefox port.

Cheers,
Mezz

> Bye,
> Alexander.


-- 
mezz7@cox.net  -  mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome@FreeBSD.org
Comment 6 Alexander Leidinger freebsd_committer 2006-02-11 21:24:29 UTC
Responsible Changed
From-To: trevor->mezz

Over to submitter: maintainer reset
Comment 7 Jeremy Messenger freebsd_committer 2006-02-25 16:45:38 UTC
State Changed
From-To: open->closed

hrs has took care of everything, thanks! Closing it...