Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

On Aug 7, 2020, at 10:49, Ken Cunningham wrote:

> By the way, for an SDK port, Gcenx has done one in an interesting way that 
> might be useful too.
> 
> 

Well that's just my port with further modifications. When I get back to looking 
into this port again, I'll continue from where I left off with my port; I don't 
want to have to puzzle out what someone else did to my port without talking to 
me about it. People are welcome to make changes to ports and contribute the 
changes back to us, at which point we can discuss their merits, or they can 
modify ports for their own personal use, which appears to be what's happened 
here, in which case it's theirs and not my concern.

Re: port "cask" -- installing prebuilt binaries

[Nils Breunese]

OpenJDK is open source, so it can be built from source. However, it is quite a 
complex and lengthy build. As the maintainer of the openjdk* ports I decided to 
use the binaries provided by the AdoptOpenJDK (for the HotSpot VM and OpenJ9 VM 
based JDK’s) and GraalVM projects. I personally wouldn’t want to replicate 
their builds in MacPorts and I don’t think anyone would enjoy waiting for 
MacPorts to build OpenJDK from source on their machine, because that can take a 
couple of hours. But theoretically the openjdk* ports could be changed to build 
from source. If anyone wants to have a go at that, be my guest!

Nils.

> Op 7 aug. 2020 om 10:09 heeft Georges Martin  het 
> volgende geschreven:
> 
> Good point.
> 
> And I just updated postgresql-jdbc, which depends on binary-only openjdk*... 
> :-|
> 
>> Le 7 août 2020 à 08:59, Ryan Schmidt  a écrit :
>> 
>> 
>> 
 On Aug 5, 2020, at 07:52, Georges Martin wrote:
>>> 
>>> If MacPorts starts to mix both approaches, I worry we may end up having 
>>> (open source) packages depending on closed source, binary packages.
>> 
>> We already have that, by necessity. For example, php-excel is an open source 
>> php module that depends on the closed-source libxl library, for which we 
>> have a port. php-oracle, an open source php module distributed as part of 
>> php itself, depends on the closed-source oracle-instantclient library, for 
>> which we have a port.

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

nope, variant is just wrong in all ways.

K

Re: port "cask" -- installing prebuilt binaries

[Arno Hautala]

> On 7 Aug 2020, at 09:04, Ken Cunningham  
> wrote:
> 
> If we use only category to mark as a binary port, what if we have a binary 
> port added (e.g. say lazarus) but then we later find out we can build that 
> port on some systems? Then we want the binary lazarus moved to 
> lazarus-binary, so we can have a real lazarus port that builds from source 
> named lazarus.

> I'm back to using the name to mark binary ports. I believe we will regret not 
> doing that in the end if we don't do it at the start.


I think the naming could indeed be a headache and a port effectively 
conflicting with itself (binary vs source) is something that should be avoided. 
I just don’t think the name is the right place for that.

I think I now prefer the variant as the right way to label and deconflict this. 
Yes, it implies it’s an option, but ports already provide default variants and 
a portfile could already fail the install if the “prebuilt” variant is manually 
removed from an install request of a port that only provides a prebuilt option.

The variants.conf file could even list ‘-prebuilt’ to keep these ports from 
“poisoning” your installation as dependents.

Using the variant solves the naming conflict, is more visible than using a 
category, and doesn’t overload the port name with metadata.

My only quibble would be that I don’t particularly like “binary” or “prebuilt” 
for the variant name. Both could be confused with referring to installing from 
an archive built by the MacPorts build server. Something like “vendor_provided” 
is lengthy, but maybe clearer as to what it means?

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

pgp b2c9d448

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

On 2020-08-07, at 12:10 AM, Ryan Schmidt wrote:

> 
> 
> On Aug 6, 2020, at 21:20, Ruben Di Battista wrote:
> 
>> If they've been built somewhere by the upstream developer, shouldn't we be 
>> able to build them too and hence instead of providing them as binaries we 
>> would  fix the ports in order to build on old systems? I guess it's a matter 
>> of how hard is to fix the build environment on old systems... 
> 
> That would be my preference too. We've already addressed many of the reasons 
> why something would fail on an older system: we have newer cctools, ld64, 
> clang available in MacPorts. The one big remaining issue is that a lot of 
> Mac-specific software can only build with the latest SDK, so we need to add a 
> MacOSX.sdk port with subports to install each major version of the SDK. I 
> worked on such a port awhile back but didn't finish it: 
> https://github.com/ryandesign/macports-ports/blob/MacOSX.sdk/devel/MacOSX.sdk/Portfile
> 
> An alternative solution is to devise a method where certain ports can opt 
> into being built on a newer system. See 
> https://trac.macports.org/ticket/60878 for more on that proposal.
> 

If we can do this, I also agree we should, for many reasons.

But still there are many things that we can't.

By the way, for an SDK port, Gcenx has done one in an interesting way that 
might be useful too.

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

A few more issues:

Handling supported_archs in binary-only ports. What if binary comes only as a 
universal binary, but the user asks for only one arch? We want that one binary 
to satisfy all the situations it can.

Handling universal requests. What if user asks for universal? If binary comes 
with three arches but user asks for only two? etc

Handling std library link checking? Binaries might come with all kinds of 
different linkages, including internal stdlibs (tenfourfox). Many will need 
link checking disabled, but some will need it enabled...

If we use only category to mark as a binary port, what if we have a binary port 
added (e.g. say lazarus) but then we later find out we can build that port on 
some systems? Then we want the binary lazarus moved to lazarus-binary, so we 
can have a real lazarus port that builds from source named lazarus. ( please 
ignore the fact we already have a lazarus port - this is just illustrative).

I'm back to using the name to mark binary ports. I believe we will regret not 
doing that in the end if we don't do it at the start.

K

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

yes, it's variant names that can't have + and - in them. Momentarily crossed 
that wire.

K

> On Aug 7, 2020, at 00:01, Ryan Schmidt  wrote:
> 
> 
> 
>> On Aug 6, 2020, at 09:10, Ken Cunningham wrote:
>> 
>> So a port that installs the Zoom teleconferencing application would be 
>> called "zoom_binary". (We can't use "zoom-binary" because variants us the + 
>> and - to do their thing.)
> 
> Calling it "zoom-binary" would be fine. Yes, "+" and "-" are used to select 
> and deselect variants, but MacPorts allows "-" in port names; we already have 
> thousands of ports with "-" in their names.
> 

Re: port "cask" -- installing prebuilt binaries

[Georges Martin]

Good point.

And I just updated postgresql-jdbc, which depends on binary-only openjdk*... :-|

> Le 7 août 2020 à 08:59, Ryan Schmidt  a écrit :
> 
> 
> 
>> On Aug 5, 2020, at 07:52, Georges Martin wrote:
>> 
>> If MacPorts starts to mix both approaches, I worry we may end up having 
>> (open source) packages depending on closed source, binary packages.
> 
> We already have that, by necessity. For example, php-excel is an open source 
> php module that depends on the closed-source libxl library, for which we have 
> a port. php-oracle, an open source php module distributed as part of php 
> itself, depends on the closed-source oracle-instantclient library, for which 
> we have a port.

Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

On Aug 6, 2020, at 21:20, Ruben Di Battista wrote:

> If they've been built somewhere by the upstream developer, shouldn't we be 
> able to build them too and hence instead of providing them as binaries we 
> would  fix the ports in order to build on old systems? I guess it's a matter 
> of how hard is to fix the build environment on old systems... 

That would be my preference too. We've already addressed many of the reasons 
why something would fail on an older system: we have newer cctools, ld64, clang 
available in MacPorts. The one big remaining issue is that a lot of 
Mac-specific software can only build with the latest SDK, so we need to add a 
MacOSX.sdk port with subports to install each major version of the SDK. I 
worked on such a port awhile back but didn't finish it: 
https://github.com/ryandesign/macports-ports/blob/MacOSX.sdk/devel/MacOSX.sdk/Portfile

An alternative solution is to devise a method where certain ports can opt into 
being built on a newer system. See https://trac.macports.org/ticket/60878 for 
more on that proposal.

Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

> On Aug 6, 2020, at 13:34, Arno Hautala wrote:
> 
>> On 6 Aug 2020, at 14:06, Ken Cunningham wrote:
>> 
>> Along with name-suffix, a category was actually one of the first suggestions 
>> in the original post 50 posts ago, but how does one see which ports you have 
>> installed that are members of that category?
>> 
>> with a name suffix, easy.
>> 
>> port -v installed | grep binary
> 
> 
> Assuming a category of “binary”:
> 
>> port echo category:binary and installed
> 

Searching your installed ports by name or category is equally easy.

port installed category:binary

port installed name:binary$

Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

On Aug 6, 2020, at 10:32, Arno Hautala wrote:

> Have any developers asked for source not to be mirrored?

A few; see "port echo license:nomirror"

Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

On Aug 6, 2020, at 09:10, Ken Cunningham wrote:

> So a port that installs the Zoom teleconferencing application would be called 
> "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to 
> do their thing.)

Calling it "zoom-binary" would be fine. Yes, "+" and "-" are used to select and 
deselect variants, but MacPorts allows "-" in port names; we already have 
thousands of ports with "-" in their names.

Re: port "cask" -- installing prebuilt binaries

[Ryan Schmidt]

On Aug 5, 2020, at 07:52, Georges Martin wrote:

> If MacPorts starts to mix both approaches, I worry we may end up having (open 
> source) packages depending on closed source, binary packages.

We already have that, by necessity. For example, php-excel is an open source 
php module that depends on the closed-source libxl library, for which we have a 
port. php-oracle, an open source php module distributed as part of php itself, 
depends on the closed-source oracle-instantclient library, for which we have a 
port.