Bug 230986 - www/linux-flashplayer: Separate c6 and c7?
Summary: www/linux-flashplayer: Separate c6 and c7?
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-emulation (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-28 19:25 UTC by Jason W. Bacon
Modified: 2018-11-17 15:31 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (emulation)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason W. Bacon freebsd_committer freebsd_triage 2018-08-28 19:25:50 UTC
Flash player seems to work fine with linux_base-c7 after setting 

DEFAULT_VERSIONS+=linux=c7_64

in make.conf and building from source (tested on NOAA weather site), but running "pkg upgrade" removes all the -c7 packages and replaces them with -c6 packages.

<<<ROOT@unixdev.ceas>>> /home/bacon 1002 # pkg info|grep linux
linux-c7-alsa-lib-1.1.3        Advanced Linux Sound Architecture libraries (Linux CentOS 7.4.1708)
linux-c7-alsa-plugins-oss-1.1.1 OSS plugin for ALSA (Linux CentOS 7.4.1708)
linux-c7-atk-2.22.0            Accessibility Toolkit (Linux CentOS 7.4.1708)
linux-c7-cairo-1.14.8          Vector graphics library Cairo (Linux CentOS 7.4.1708)
linux-c7-curl-7.29.0_4         Tool for transferring files with URL syntax (Linux CentOS 7.4.1708)
linux-c7-cyrus-sasl-lib-2.1.26_3 RFC 2222 SASL (Simple Authentication and Security Layer) (Linux CentOS 7.4.1708)
linux-c7-dri-17.0.1            Mesa libGL runtime libraries (Linux CentOS 7.4.1708)
linux-c7-elfutils-libelf-0.168 ELF file handling library (CentOS 7.4.1708)
linux-c7-expat-2.1.0_2         XML 1.0 parser written in C (Linux CentOS 7.4.1708)
linux-c7-fontconfig-2.10.95_3  XML-based font configuration API for X Windows (Linux CentOS 7.4.1708)
linux-c7-gdk-pixbuf2-2.36.5    Graphic library for GTK+ (Linux CentOS 7.4.1708)
linux-c7-graphite2-1.3.10      Rendering capabilities for complex non-Roman writing systems (Linux CentOS 7.4.1708)
linux-c7-gtk2-2.24.31          GTK+ library, version 2.X (Linux CentOS 7.4.1708)
linux-c7-harfbuzz-1.3.2        OpenType text shaping engine (Linux CentOS 7.4.1708)
linux-c7-jasper-libs-1.900.1_4 JPEG-2000 reference implementation (Linux CentOS 7.4.1708)
linux-c7-jbigkit-libs-2.0_2    Lossless compression for bi-level images (Linux CentOS 7.4.1708)
linux-c7-jpeg-1.2.90_2         SIMD-accelerated JPEG codec (Linux CentOS 7.4.1708)
linux-c7-libpciaccess-0.13.4_3 Generic PCI access library (CentOS 7.4.1708)
linux-c7-libpng-1.5.13_2       Library for manipulating PNG images (Linux CentOS 7.4.1708)
linux-c7-libssh2-1.4.3_2       Library implementing the SSH2 protocol (Linux CentOS 7.4.1708)
linux-c7-libthai-0.1.14_1      Thai language support library (Linux CentOS 7.4.1708)
linux-c7-libtiff-4.0.3_3       Library routines for working with TIFF images (Linux CentOS 7.4.1708)
linux-c7-nspr-4.13.1           Netscape Portable Runtime (Linux CentOS 7.4.1708)
linux-c7-nss-3.28.4_3          Network Security Services (Linux CentOS 7.4.1708)
linux-c7-openldap-2.4.44       LDAP libraries (Linux CentOS 7.4.1708)
linux-c7-openssl-libs-1.0.2k   OpenSSL libraries (Linux CentOS 7.4.1708)
linux-c7-pango-1.40.4          Pango library (Linux CentOS 7.4.1708)
linux-c7-pixman-0.34.0         Low-level pixel manipulation library (Linux CentOS 7.4.1708)
linux-c7-sqlite-3.7.17_1       Library that implements an embeddable SQL database engine (Linux CentOS 7.4.1708)
linux-c7-xorg-libs-7.7_5       Xorg libraries (Linux CentOS 7.4.1708)
linux-flashplayer-30.0.0.154   Adobe Flash Player NPAPI Plugin
linux_base-c7-7.4.1708_6       Base set of packages needed in Linux mode (Linux CentOS 7.4.1708)
<<<ROOT@unixdev.ceas>>> /home/bacon 1003 # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (190 candidates): 100%
Processing candidates (190 candidates): 100%
The following 16 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	linux-c6-xorg-libs: 7.4_10
	linux-c6-fontconfig: 2.8.0_3
	linux-c6-expat: 2.0.1_5
	linux_base-c6: 6.9_8
	linux-c6-gtk2: 2.24.23_7
	linux-c6-pango: 1.28.1_7
	linux-c6-cairo: 1.8.8_8
	linux-c6-pixman: 0.32.8_1
	linux-c6-libpng: 1.2.49_5
	linux-c6-libthai: 0.1.12_1
	linux-c6-gdk-pixbuf2: 2.24.1_5
	linux-c6-libtiff: 3.9.4_5
	linux-c6-jpeg: 1.2.1_3
	linux-c6-jasper-libs: 1.900.1_4
	linux-c6-atk: 1.30.0_2

Installed packages to be REINSTALLED:
	nspluginwrapper-1.4.4_7 (direct dependency changed: linux-c6-gtk2)

Number of packages to be installed: 15
Number of packages to be reinstalled: 1

The process will require 240 MiB more space.
38 MiB to be downloaded.

Proceed with this action? [y/N]: 

Is there a way to prevent this from happening?
Comment 1 rkoberman 2018-08-28 23:39:24 UTC
The problem is that c6 is still the default. I have no idea why as I have been running c7 for many months with no issues. The package database is always built with all defaults, so c6.

A solution is to create a linux-c7-flashplayer which depends on linux_base-c7. Otherwise it can be identical to the current port.

An easy work-around is simply to build from the port. It's just a binary blob so takes seconds to install the port. Another solution is to mark the port as not to be packaged at all, but that would cause more issues than it's worth, especially with flash rapidly disappearing from the web.

You might create a port adding:
CONFLICTS=      linux-flashplugin-[0-9]*
and
USES= linux:c7
and submit it.
Comment 2 Jason W. Bacon freebsd_committer freebsd_triage 2018-08-29 01:14:39 UTC
Yes, I'm aware that installing via make is easy, but that's not the problem.  The problem as that after doing so, the installation of all the c7 ports will get wiped and replaced with c6 equivalents by "pkg upgrade".

So it seems we should have separate c6 and c7 ports, as we used to with linux-c*-flashplugin.

Both were replaced by a single linux-flashplayer port, so I wondered if this change came with a clever way to preserve either a c6 or c7 environment through pkg upgrades.

Since it apparetnly did not, I would propose that we replace linux-flashplayer with linux-c6-flashplayer and linux-c7-flashplayer, which would be virtually identical except for USES=linux:c*.
Comment 3 rkoberman 2018-08-29 06:03:15 UTC
(In reply to Jason W. Bacon from comment #2)
I'm afraid not. There is no dependency in linux-flashplayer is linux version agnostic. It will happily build with either c6 or c7. I build it that way quite regularly. Her it is:
# pkg info linux_base\*
linux_base-c7-7.4.1708_6
# make
===>   linux-flashplayer-30.0.0.154 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by linux-flashplayer-30.0.0.154 for building
===>  Extracting for linux-flashplayer-30.0.0.154
=> SHA256 Checksum OK for flashplayer/30.0.0.154/flash_player_npapi_linux.i386.tar.gz.
===>  Patching for linux-flashplayer-30.0.0.154
===>  Configuring for linux-flashplayer-30.0.0.154
===>  Staging for linux-flashplayer-30.0.0.154
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-alsa-lib>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-alsa-plugins-oss>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-curl>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-dri>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-gtk2>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-nspr>0 - found
===>   linux-flashplayer-30.0.0.154 depends on package: linux-c7-nss>0 - found
===>   Generating temporary packing list
/bin/mkdir -p /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/linux-flashplayer
install   -m 0644 /usr/ports/www/linux-flashplayer/work/linux-flashplayer-30.0.0.154/libflashplayer.so /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/linux-flashplayer
install   -m 555 /usr/ports/www/linux-flashplayer/work/linux-flashplayer-30.0.0.154/usr/bin/flash-player-properties /usr/ports/www/linux-flashplayer/work/stage/usr/local/bin
install  -m 0644 /usr/ports/www/linux-flashplayer/work/linux-flashplayer-30.0.0.154/usr/share/applications/flash-player-properties.desktop /usr/ports/www/linux-flashplayer/work/stage/usr/local/share/applications
(cd /usr/ports/www/linux-flashplayer/work/linux-flashplayer-30.0.0.154/usr/share/icons && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE hicolor /usr/ports/www/linux-flashplayer/work/stage/usr/local/share/icons)
/bin/mkdir -p /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-firefox
/bin/ln -sf /usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-firefox/
/bin/mkdir -p /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-opera
/bin/ln -sf /usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-opera/
/bin/mkdir -p /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-opera-devel
/bin/ln -sf /usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-opera-devel/
/bin/mkdir -p /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-seamonkey
/bin/ln -sf /usr/local/lib/browser_plugins/linux-flashplayer/libflashplayer.so /usr/ports/www/linux-flashplayer/work/stage/usr/local/lib/browser_plugins/symlinks/linux-seamonkey/
====> Compressing man pages (compress-man)
# 

As you can see, it i perfectly happy using the c7 ports.
Comment 4 rkoberman 2018-08-29 06:08:27 UTC
Just re-read the ticket and it i clear that you have used 'make' to make the port. If you can do that, you can do a "make package" and use that package to install on other system with c7 paskages installed, though it would be a bit safer to use poudriere or synth.
Comment 5 Tijl Coosemans freebsd_committer freebsd_triage 2018-08-29 08:05:24 UTC
Try pkg-lock(8).
Comment 6 Jason W. Bacon freebsd_committer freebsd_triage 2018-08-30 14:08:22 UTC
I'm not looking for a workaround for myself, I'm trying to solve this problem permanently for all FreeBSD users.

It appears that the only way to do that is by having separate c7 packages in the main repo.

I added the necessary ports to my WIP collection so others can easily test them:

https://github.com/outpaddling/freebsd-ports-wip
Comment 7 Tijl Coosemans freebsd_committer freebsd_triage 2018-08-30 15:15:21 UTC
But why single out linux flashplayer?  Why not all the other linux ports too?  And what's so bad about c6?  Is there something that doesn't work?  If you want to go ahead with this I think it would be better to use flavors.
Comment 8 rkoberman 2018-08-30 23:24:07 UTC
(In reply to Jason W. Bacon from comment #6)
Your point is valid, but this is the wrong forum as the problem is the packaging system. It expects to install a package on a system that has the exact versions of all dependencies that were used to build the package. This is important as it assures that there will be no differences that might impact the performance of the package. and, of course, the packaging system assumes that the latest default dependencies are used.

In the case of linux packages, that means c6 for 10 and 11. It seems likely that c7 might become the default at come point, hopefully in the near future. Until that happens, I can't see any resolution of this problem. For me it would mean using c6 and at least two ports that have vulnerabilities that I was informed were unlikely to be fixed in c6. (That was as of at least a year ago, so may be no longer true.)

Sorry, but I don't think that there is a solution available.
Comment 9 rkoberman 2018-08-30 23:35:33 UTC
(In reply to Tijl Coosemans from comment #7)
For the record, there are now 61 linux port that are not version specific.

As to why not c6, I moved to c7 because of two ports that had known vulnerabilities and, since c6 was no longer getting security fixes, c7 was the obvious solution. That c6 was no longer getting updates was not confirmed by me. I just know that one of the vulnerable ports had been there for well over a year.
Comment 10 Jason W. Bacon freebsd_committer freebsd_triage 2018-08-31 00:11:00 UTC
CentOS 6 is nearing EOL and support from vendors is already waning.  We need to make c7 practical for average users to manage before that happens, so it can be well tested before becoming the default.

I don't much care what the solution looks like, but I think it's important that people can choose freely between c6 and c7, and safely run a pkg upgrade in either case.

I'll explore using flavors instead of separate ports.  The only major shortcoming with c7 is the lack of binary packages for flashplayer and comparable ports, so any solution that gets both c6 and c7 variants of the packages into the repo would be satisfactory from my perspective.

I think it would be ideal if the system tried to build c6 and c7 flavors by default (unless otherwise specified), as it does with python 2 & 3.  I suspect some people will want to stick with c6 for some time after EOL for their own valid reasons, so it will be important for both c6 and c7 to be well supported for a while.

Many of us need to move onto c7 in the near future, though.  We will not longer be running any real CentOS 6 systems after 2018.

I'm beginning to test a variety of engineering apps from ANSYS, Biovia, etc.  I know linux compatibility is not a high priority for most FreeBSD users, but we're in a good position right now to polish it up and make FreeBSD a more viable platform for running commercial apps. 64-bit support and c7 are working pretty well now, and RHEL/CentOS 7 are still young.  Any investment we make in improving the system now will have a lasting benefit for the next several years.
Comment 11 Johannes Jost Meixner freebsd_committer freebsd_triage 2018-09-03 07:57:37 UTC
Adding some history:

* We had separate ports for f10 and c6 years, before c7 was a thing. This was then scrapped in r428854, merging c6 and c7 ports into one.
* Defaulting to c7 may be a bad idea for people running "legacy" i386 (which is still a Tier 1 architecture)
* CentOS 6 goes end of life on 30 Nov, 2020, so there's plenty of time for us to ditch it -- in the future. "Nearing EOL" is perhaps an overstatement.
* I would see flavors as the way forward, this would allow for more dynamic package dependencies.
Comment 12 Jason W. Bacon freebsd_committer freebsd_triage 2018-09-03 14:26:25 UTC
While the final EOL date is a long way off, full support and maintenance support1 have already ended:

https://access.redhat.com/support/policy/updates/errata
https://wiki.centos.org/About/Product

More importantly, vendors are beginning to drop support for it in their latest releases, e.g. we cannot run some CUDA scientific apps until we upgrade our CentOS systems to 7.

I agree that flavors are likely the best solution.  I'll experiment with the flashplayer ports ASAP and post results here.
Comment 13 Tijl Coosemans freebsd_committer freebsd_triage 2018-09-03 15:30:16 UTC
(In reply to Jason W. Bacon from comment #12)
> I agree that flavors are likely the best solution.  I'll experiment
> with the flashplayer ports ASAP and post results here.

Ideally you'd implement this in Mk/Uses/linux.mk (if you're interested of course).  Something like this maybe:

USES=linux        # all flavors (c6, c6_64 (amd64 only), c7)
USES=linux:c6     # no flavors, just depend on c6
USES=linux:c6,c7  # c6 and c7 flavor
Comment 14 Jason W. Bacon freebsd_committer freebsd_triage 2018-11-17 15:31:09 UTC
Thanks for the feedback.  Will explore this in a broader context when time permits.