Re: What's the push to require the latest Perl?

[Dave Horsfall]

On Thu, 11 Jan 2018, Daniel J. Luke wrote:

MacPorts doesn't support version comparisons in dependency 
specifications (this is a really old issue that's been discussed a lot 
over the years).


Ah.

I look forward to seeing your contributions! Maybe you will come up with 
a solution that no one else has thought of yet. :)


OK, where do I start?  I wasn't joking when I offered to help...

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Re: What's the push to require the latest Perl?

[Daniel J. Luke]

On Jan 11, 2018, at 3:33 PM, Dave Horsfall  wrote:
> You might want to note that FreeBSD ports uses a ">=" test on versions e.g. 
> Perl 5.26 will satisfy the 5.24 requirement (unless, of course, there was the 
> aforesaid technical reason why it cannot).

MacPorts doesn't support version comparisons in dependency specifications (this 
is a really old issue that's been discussed a lot over the years).

> And if it comes down to a simple manpower issue, then let the record show
> that I am willing to help if it will avoid people (like me) having to
> have multiple versions of Perl bloatware (which reason, by the way, is why 
> I'm starting to move to Ruby instead; Python is for the birds).

I look forward to seeing your contributions! Maybe you will come up with a 
solution that no one else has thought of yet. :)

-- 
Daniel J. Luke

Re: lib dependency confusion

[Jan Stary]

On Jan 11 06:23:11, ryandes...@macports.org wrote:
> >>> $ port installed depends:libressl
> >>> None of the specified ports are installed.
> >> 
> >> This result means: of the ports that specify a dependency containing the 
> >> substring "libressl", you don't have any installed. 
> > 
> > OK, what is the right way to ask port(1)
> > 
> > "which of my currently installed ports
> > do depend on the installed libressl"?
> 
> I'm not aware of a way to get the answer to that question,

Well, this seems like a very obvious question
for a package management system, right?

Re: Portable apps

[Ryan Schmidt]

On Jan 11, 2018, at 10:23, Michael wrote:

> On 2018-01-11, at 4:37 AM, Ryan Schmidt wrote:
> 
>> openssl provides libssl.1.0.0.dylib. The absolute path 
>> /opt/local/lib/libssl.1.0.0.dylib is baked into the lynx executable as a 
>> library that it needs in order to run. This is not special to lynx or 
>> openssl; this is how programs and libraries work on macOS.
> 
> How is it possible then to make a binary that can be distributed without that 
> binary being dependent on specific machine configurations?

To make a redistributable app, copy all the libraries into the application 
bundle, and use install_name_tool to change all their install_names and 
inter-library linkages to use a relative instead of absolute path (e.g. using 
"@loader_path" or "@rpath"). The dylibbundler program (installable via 
MacPorts) automates that.


> I'm specifically thinking of OBS. Trying to compile OBS from source code 
> results in an executable that is approximately one tenth the size of the 
> officially distributed one, that is not portable to other people's machines, 
> unless every library is in the exact same spot (Homebrew vs macports, or in 
> one case, one person's ~/lib.).

Re: port:openssl dependency

[Ryan Schmidt]

On Jan 11, 2018, at 01:08, Jan Stary wrote:
> On Jan 10 15:53:59, Daniel Luke wrote:
>> On Jan 10, 2018, at 2:49 PM, Jan Stary wrote:
>>> these ports specify a hard dependency on openssl with "port:openssl".
>> 
>> is libressl now ABI compatible with openssl? IIRC some ports moved from path 
>> back to port style dependencies on openssl since libressl was only 'source' 
>> compatible and so if you have a path-style dependency and users get things 
>> from the buildbot (that were built against openssl) they get non-working 
>> ports
> 
> If you have libressl installed and install e.g. lynx with
> 'port install lynx', it downloads the precompiled lynx,
> installs  it, and reports it as broken, offering to rebuild.
> If you agree to rebuild, it recompiles against the installed libressl.

Correct.

> How exactly is the decision made about lynx being 'broken'
> in this situation?

When a port such as lynx that has a dependency on path:lib/libssl.dylib:openssl 
builds on our buildbot, it always builds with openssl. This is because when the 
buildbot begins building any port, no ports are activated, so there is no file 
at the path ${prefix}/lib/libssl.dylib.

libssl.dylib is actually not a file, but a symlink, pointing to the version of 
the library the port provides.

openssl provides libssl.1.0.0.dylib. The absolute path 
/opt/local/lib/libssl.1.0.0.dylib is baked into the lynx executable as a 
library that it needs in order to run. This is not special to lynx or openssl; 
this is how programs and libraries work on macOS.

libressl does not provide libssl.1.0.0.dylib; it provides libssl.43.dylib.

rev-upgrade runs after every install and upgrade, and checks the library paths 
baked into all the executables and libraries installed by MacPorts. If a port 
contains a program or library, and that program or library specifies the path 
of another library that does not exist, the port is considered broken.

This is why it was a mistake for MacPorts to use a "path:lib/ssl.dylib:openssl" 
dependency for the purpose of allowing a user to switch an openssl-using port 
to libressl. openssl and libressl do not use the same library versioning scheme 
so they are not drop-in replacements for one another. We should have done it 
differently, e.g. with variants. See https://trac.macports.org/ticket/54744.