#54633 closed defect (fixed)
ffmpeg, ffmpeg-devel: not distributable on Snow Leopard
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | jeremyhu (Jeremy Huddleston Sequoia), mojca (Mojca Miklavec), danchr (Dan Villiom Podlaski Christiansen), dbevans (David B. Evans) | |
Port: | ffmpeg, ffmpeg-devel |
Description (last modified by mascguy (Christopher Nielsen))
ffmpeg and ffmpeg-devel are not distributable on 10.6, but they are on all later MacOS releases.
Any idea how we could fix them to be distributable on 10.6 too?
Change History (20)
comment:1 Changed 7 years ago by mojca (Mojca Miklavec)
Cc: | mojca added |
---|
comment:2 Changed 4 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:3 Changed 3 years ago by mascguy (Christopher Nielsen)
comment:4 follow-up: 16 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | danchr added |
---|
FYI, I built MacPorts with @Danchr's excellent work related to issue:60315, and here's our answer:
$ port licensecheck ffmpeg ---> Checking license for ffmpeg Warning: "ffmpeg" is not distributable because its license "GPL" conflicts with license "OpenSSL": librsvg -> glib2 -> python27 -> openssl Warning: "ffmpeg" is not distributable because its license "GPL" conflicts with license "SSLeay": librsvg -> glib2 -> python27 -> openssl
After the addition of license_noconflict openssl
:
$ port licensecheck ffmpeg ---> Checking license for ffmpeg "ffmpeg" is distributable
So my first thought is, we REALLY need to add Dan's licensecheck
functionality to base. IMHO, I think we should strongly consider adding it to the pending release (albeit with the change to move license data under _resources
), as the risk is minimal.
As for ffmpeg
, given the dependency chain, is the openssl
license a problem in this case?
comment:5 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | dbevans added; mascguy removed |
---|---|
Owner: | changed from dbevans to mascguy |
Status: | new → assigned |
comment:6 Changed 3 years ago by kencu (Ken)
the ffmpeg license is supposed to be LGPL-2+, which is distributable, unless you specifically enable the gpl2 variant, and then it is non-distributable due to the openssl mess (which disappears this year with openssl 3.0, we all hope).
Did that get messed up?
comment:7 Changed 3 years ago by mascguy (Christopher Nielsen)
Summary: | ffmpeg, ffmpeg-devel: not distributable on Snow Leopard or Lion → ffmpeg, ffmpeg-devel: not distributable on Snow Leopard |
---|
comment:8 Changed 3 years ago by mascguy (Christopher Nielsen)
Ken, this is only happening for the MacOS 10.6 case, which is curious. And +gpl2
has been the default for a long time, without an issue for later MacOS releases.
comment:9 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:10 Changed 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:11 Changed 3 years ago by kencu (Ken)
it looks like the gpl2 variant is enabled by default somehow. for any software that has a chain that leads to openssl, that makes it non-distributable. Disabling gpl2 on 10.6 (etc) should do it.
IMHO, YMMV, etc
comment:12 Changed 3 years ago by kencu (Ken)
maybe some dep of a dep of a dep added a dep on openssl and brought the whole house of cards down...
comment:13 Changed 3 years ago by kencu (Ken)
gpl2+ was enabled 10 years ago, I see. Looks like not a good idea to disable gpl2+. probably shouldn't even be a variant, just enable it always, but leave that for Ryan and Josh.
So, 10.6ers are still building it then, I guess until openssl 3.0 comes along.
comment:14 follow-up: 15 Changed 3 years ago by mascguy (Christopher Nielsen)
Well, the output of port licensecheck
shows us the dependency chain, so there's no longer a mystery:
license "GPL" conflicts with license "OpenSSL": librsvg -> glib2 -> python27 -> openssl license "GPL" conflicts with license "SSLeay": librsvg -> glib2 -> python27 -> openssl
Taking this a step further, and reviewing the dependencies of glib2
:
$ port deps glib2 os.major=10 Full Name: glib2 @2.58.3_1+x11 Extract Dependencies: xz Build Dependencies: autoconf, automake, libtool, libxml2, pkgconfig, clang-3.7 Library Dependencies: gettext, libffi, libiconv, pcre, zlib, python27, libcxx $ port deps glib2 os.major=11 Full Name: glib2 @2.58.3_1+x11 Extract Dependencies: xz Build Dependencies: autoconf, automake, libtool, libxml2, pkgconfig, clang-3.7 Library Dependencies: gettext, libffi, libiconv, pcre, zlib
We can see that glib2
has a lib dependency on python27
, that only exists for 10.6. And per the glib2
portfile:
if {${os.platform} eq "darwin" && ${os.major} <= 10} { # Requires python 2.7 as of 2.53.4 # See https://bugzilla.gnome.org/show_bug.cgi?id=785193 depends_lib-append port:python27 configure.python ${prefix}/bin/python2.7 }
So I think that's our answer. Ryan, does glib2
truly have a lib dependency on python27
? Or is it build-time only?
comment:15 follow-up: 17 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
comment:16 follow-up: 18 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mascguy:
So my first thought is, we REALLY need to add Dan's
licensecheck
functionality to base. IMHO, I think we should strongly consider adding it to the pending release
Josh tagged 2.7.0-rc1 tonight, so that would mean that only commits that fix showstopping bugs should be cherry-picked to the 2.7 branch at this point. Let's get the fix in master and it can go into 2.7.1.
comment:17 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to ryandesign:
Replying to mascguy:
Ryan, does
glib2
truly have a lib dependency onpython27
?Yes, according to #17530.
Okay, so is it fair to say that binaries aren't publishable for ffmpeg
[on 10.6], until the upstream openssl
license changes?
comment:18 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to ryandesign:
Replying to mascguy:
So my first thought is, we REALLY need to add Dan's
licensecheck
functionality to base. IMHO, I think we should strongly consider adding it to the pending releaseJosh tagged 2.7.0-rc1 tonight, so that would mean that only commits that fix showstopping bugs should be cherry-picked to the 2.7 branch at this point. Let's get the fix in master and it can go into 2.7.1.
Sounds good. I reached out to the Dan almost a week ago, and haven't heard back. So I'll close his PR, and open a new one, with the updated work.
comment:19 Changed 3 years ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This issue will be resolved once the upstream openssl license changes. Closing.
comment:20 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
I don't know whether it is legal to specify an openssl exception for this case; I have not attempted to figure it out.
It would be better to update the existing PR than to close it and open a new one.
Also see comments in duplicate ticket issue:62851.