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
Responsible Changed From-To: freebsd-ports-bugs->trevor To maintainer of acroread7
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
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
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
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
Responsible Changed From-To: trevor->mezz Over to submitter: maintainer reset
State Changed From-To: open->closed hrs has took care of everything, thanks! Closing it...