Bug 63059 - linux-flashplugin LATEST_LINK and RESTRICTED fixes
Summary: linux-flashplugin LATEST_LINK and RESTRICTED fixes
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: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-19 10:00 UTC by Brandon D. Valentine
Modified: 2004-02-27 22:00 UTC (History)
0 users

See Also:


Attachments
linux-flashplugin_20040219.patch (7.02 KB, patch)
2004-02-19 10:00 UTC, Brandon D. Valentine
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon D. Valentine 2004-02-19 10:00:20 UTC
  Maintainer Updates:

  linux-flashplugin:

  1) Change MAINTAINER from ports@FreeBSD.org to
  ports@brandon.dvalentine.com.  I am volunteering to take over
  maintainership.
  2) Makefile and pkg-plist cleanup.  Switch to using PORTDOCS and
  DOCSDIR.
  3) Set NO_PACKAGE and RESTRICTED.  Macromedia license forbirds
  redistribution.
  4) Set LATEST_LINK to avoid collision with linux-flashplugin6.

  linux-flashplugin6:

  1) Update MAINTAINER email address.
  2) Set LATEST_LINK to avoid collision with linux-flashplugin.
  3) Makefile and pkg-plist cleanup.  Switch to using PORTDOCS and
  DOCSDIR.
  4) Set NO_PACKAGE and RESTRICTED.  Macromedia license forbirds
  redistribution.

  This patch also updates ports/LEGAL to document the license
  restrictions.   The Macromedia license can be found here:
  http://www.macromedia.com/shockwave/download/license/desktop/

  The crucial clause is 3a which states:

  "You may not make or distribute copies of the Software, or
  electronically transfer the Software from one computer to another or
  over a network."

  I have marked this PR serious because I believe it is important to get
  the license issue corrected as soon as possible.

How-To-Repeat: 	N/A
Comment 1 Oliver Eikemeier 2004-02-25 22:51:57 UTC
Brandon D. Valentine wrote:

Brandon D. Valentine wrote:

> --- linux-flashplugin/pkg-plist	21 Jul 2001 14:27:22 -0000	1.4
> +++ linux-flashplugin/pkg-plist	19 Feb 2004 09:45:17 -0000
...
> -%%PLUGINSDIR%%/ShockwaveFlash.class
> -%%PLUGINSDIR%%/libflashplayer.so
...
> +@unexec rm -f %D/%%PLUGINSDIR%%/ShockwaveFlash.class %D/%%PLUGINSDIR%%/libflashplayer.so


> --- linux-flashplugin6/pkg-plist	19 Jun 2003 02:18:51 -0000	1.2
> +++ linux-flashplugin6/pkg-plist	19 Feb 2004 09:45:17 -0000
...
> -%%PLUGINSDIR%%/flashplayer.xpt
> -%%PLUGINSDIR%%/libflashplayer.so
...
> +@unexec rm -f %D/%%PLUGINSDIR%%/flashplayer.xpt %D/%%PLUGINSDIR%%/libflashplayer.so

Is there a reason for doing this?

Oliver
Comment 2 brandon 2004-02-26 00:07:04 UTC
On Wed, Feb 25, 2004 at 11:51:57PM +0100, Oliver Eikemeier wrote:
> 
> Is there a reason for doing this?

Yes.  Though I must admit that it just took me a few minutes to remember
why myself.

In the do-install target I have made these changes:

-	@${MKDIR} ${PREFIX}/${PLUGINSDIR}
-	@${LN} -sf ${PREFIX}/lib/linux-flashplugin6/${f} ${PREFIX}/${PLUGINSDIR}/
+.if exists(${PLUGINSDIR})
+	@${LN} -sf ${PREFIX}/lib/linux-flashplugin6/${f} ${PREFIX}/${PLUGINSDIR}
+.endif

Both ports previously did the wrong thing and created PLUGINSDIR whether
the netscape-linux or linux-mozilla ports were installed or not.  Now,
the port will only install symlinks if those ports are already
installed.  If those browsers are installed after flash is installed,
the linkfarm scripts included with those browsers will find these
plugins and create those symlinks on their own.  Because I no longer
explicity create PLUGINSDIR, I can't rely on it existing during
deinstall.  I couldn't list the symlinks in pkg-plist any longer because
there would be errors during deinstall on systems without one of those
browser ports installed.  "@unexec rm -f" will always succeed even if
the files don't exist and deinstall will not emit any errors.  I have
seen several other ports use this trick.

An alternative I have considered is to conditionally set
%%PLUGINSDIR%% to "@comment" via PLIST_SUB when the PLUGINSDIR doesn't
exist.  The problem with that is this scenario:

1) User installs linux-flashplugin6.
2) User installs linux-mozilla.
3) linux-mozilla port's linkfarm script installs symlink into PLUGINSDIR.
4) User deinstalls linux-flashplugin6.
5) There's now a dead symlink in PLUGINSDIR.

The way I've chosen to do it at least ensures that the symlinks always
get cleaned up.

Perhaps I shouldn't be removing symlinks created by another port, but at
present those ports create symlinks at install time based on whether my
ports are installed.  There are uglier things lurking in the linux
browser ports.

I have been thinking for some time about proposing a central
linux_browser_plugins directory similar to the
${X11BASE}/lib/browser_plugins.  This would go a long way toward taking
care of the various hacks strewn throughout ports related to Linux
browsers and plugins.  This however will require effort on the part of
many port maintainers and I wasn't ready to tackle it in this update.

HTH,

Brandon D. Valentine
-- 
brandon@dvalentine.com                           http://www.geekpunk.net
Pseudo-Random Googlism:  february is juvenile firesetters prevention
                         month
Comment 3 Oliver Eikemeier 2004-02-26 00:31:36 UTC
Brandon D. Valentine wrote:

> In the do-install target I have made these changes:
> 
> -	@${MKDIR} ${PREFIX}/${PLUGINSDIR}
> -	@${LN} -sf ${PREFIX}/lib/linux-flashplugin6/${f} ${PREFIX}/${PLUGINSDIR}/
> +.if exists(${PLUGINSDIR})
> +	@${LN} -sf ${PREFIX}/lib/linux-flashplugin6/${f} ${PREFIX}/${PLUGINSDIR}
> +.endif
> 
> Both ports previously did the wrong thing and created PLUGINSDIR whether
> the netscape-linux or linux-mozilla ports were installed or not.  Now,
> the port will only install symlinks if those ports are already
> installed.  If those browsers are installed after flash is installed,
> the linkfarm scripts included with those browsers will find these
> plugins and create those symlinks on their own. [...]
> 
> 1) User installs linux-flashplugin6.
> 2) User installs linux-mozilla.
> 3) linux-mozilla port's linkfarm script installs symlink into PLUGINSDIR.
> 4) User deinstalls linux-flashplugin6.
> 5) There's now a dead symlink in PLUGINSDIR.
> 
> The way I've chosen to do it at least ensures that the symlinks always
> get cleaned up.
> 
> Perhaps I shouldn't be removing symlinks created by another port, but at
> present those ports create symlinks at install time based on whether my
> ports are installed.  There are uglier things lurking in the linux
> browser ports.

Ok, I understand what should be done here. May I make two suggestions:

- it would be nice to have the link creation in a pkg-install script,
  since the autodetection fails if the port is installed from a package

- a more-or-less short comment what would be removed and why wouldn't be bad,
  (especially because this may remove symlinks not created by the port).
  I'm not sure where to place this comments, though. Perhaps the pkg-install
  script where the links are created is a good place.

You can execute the post-install script with something like

post-install:
	${SETENV} "PKG_PREFIX=${PREFIX}" ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL

to avoid code duplication, but this may make your Makefile longer if this is the
only thing you do in port-install.

Otherwise the patches look good to me
    Oliver
Comment 4 brandon 2004-02-27 21:08:41 UTC
On Thu, Feb 26, 2004 at 01:31:36AM +0100, Oliver Eikemeier wrote:
> 
> Ok, I understand what should be done here. May I make two suggestions:

Thanks for reviewing this, Oliver.

> - it would be nice to have the link creation in a pkg-install script,
>  since the autodetection fails if the port is installed from a package

The port sets NO_PACKAGE and RESTRICTED.  Do I still need to worry about
pkg-install time?  =)

> - a more-or-less short comment what would be removed and why wouldn't be 
> bad,
>  (especially because this may remove symlinks not created by the port).
>  I'm not sure where to place this comments, though. Perhaps the pkg-install
>  script where the links are created is a good place.

I'm not sure where the best place to put this is either.  Should I just
put a comment in the Makefile or do I need to print a warning to the
user at install time?

Thanks,

Brandon D. Valentine
-- 
brandon@dvalentine.com                           http://www.geekpunk.net
Pseudo-Random Googlism:  brandon is een experiment plaats met unieke
                         jurysoftware
Comment 5 Oliver Eikemeier freebsd_committer freebsd_triage 2004-02-27 21:44:13 UTC
State Changed
From-To: open->closed

Committed, thanks!
Comment 6 Oliver Eikemeier 2004-02-27 21:51:02 UTC
Brandon D. Valentine wrote:
> On Thu, Feb 26, 2004 at 01:31:36AM +0100, Oliver Eikemeier wrote:
> 
>>Ok, I understand what should be done here. May I make two suggestions:
> 
> Thanks for reviewing this, Oliver.

You are welcome. Thanks for your explanations.

>>- it would be nice to have the link creation in a pkg-install script,
>> since the autodetection fails if the port is installed from a package
> 
> The port sets NO_PACKAGE and RESTRICTED.  Do I still need to worry about
> pkg-install time?  =)

Maybe. Users might decide to build packages locally (eg to update multiple
machines, like a lab).

>>- a more-or-less short comment what would be removed and why wouldn't be 
>>bad,
>> (especially because this may remove symlinks not created by the port).
>> I'm not sure where to place this comments, though. Perhaps the pkg-install
>> script where the links are created is a good place.
> 
> I'm not sure where the best place to put this is either.  Should I just
> put a comment in the Makefile or do I need to print a warning to the
> user at install time?

No, I guess users aren't really interested. It's more stupid committers asking
the same stupid questions over & over again.

Maybe you want to include some of this in the next revision.

Oliver