Re: Meson 0.56.2 and Python39 --> dav1d failing

[Ryan Schmidt]

On Feb 4, 2021, at 11:26, Ken Cunningham wrote:

> wait, I could have missed the issue...if meson is now adding a default 
> argument to all checks that means it can never build anything with the 
> default compilers on <10.10, that would be something we should consider 
> fixing in meson, even if upstream doesn't want to.
> 
> So if testing shows that all builds on 10.7 -10.9 of meson ports are broken, 
> then yeah, that's different, sure.

That sounds like what Craig is saying: that meson is now adding a compiler flag 
that old compilers don't understand. Meson should check whether a compiler 
supports a flag before it adds it. We should not be responsible for fixing 
this; the developers of meson should.

Re: "cask" ports just keep on rolling in...

[Ryan Schmidt]

On Feb 5, 2021, at 13:00, Ken Cunningham wrote:

> With no plan, we’ll just keep getting more and more of these.

I'm not aware of a huge influx of these, but I'm also not really paying 
attention to the PR queue. And I'm not intending to get drawn into this 
discussion of binary ports again.


> 
> 
> This kind of port just repackages the DMG into many tgz archives.
> 
> It’s wasteful. People want them.
> 
> What we should have instead of this is some kinda tech that
> 
> 1. downloads the DMG
> 2. installs the app
> 3. records some way of uninstalling everything

MacPorts already does all these things... The submitted Portfile works fine, 
presumably. There's no need to reinvent the existing MacPorts functionality 
that does all these things.


> What we have instead is a repackaging of the DMG into many, identical, 
> system-specific archive bundles.
> 
> Yuk.

If your objection is that we waste server space storing several copies of the 
same thing, then we could invent a new way for a portfile to indicate that it 
does not want binary archives stored on the server. It could be a new separate 
keyword or a new pseudo license type, like we already have for "nomirror" which 
tells the buildbot not to mirror the distfiles.

A port like the one we're talking about in the above PR could set e.g. "license 
GPL-2 nopackage", and buildbot could be modified to understand that this means 
that it should not upload the packages.

MacPorts base would still try to download the nonexistent package. MacPorts 
base currently does not use license values except to display to the user and 
has no idea if a port is distributable. Distributability is handled by a 
separate script. It should be integrated into base so that base can know if 
something could have been distributed, and if it could not have, then it 
shouldn't even try to download it. https://trac.macports.org/ticket/60315

We might also want to modify the MacPorts base command line "-b" binary only 
mode to allow installing these "nopackage" ports rather than error out as it 
would currently do.

If the few steps like disabling the configure and build phases and adding the 
hypothetical "nopackage" to the license line are too much work for a portfile 
submitter to do, a portgroup could be created that does those things. But you 
have often complained about "magic" portgroups doing things you didn't know 
about or didn't expect, so there is something to be said for ports doing what 
they need to do explicitly, when it's not so many steps, and when it's not 
always the same steps needing to be done. For example, surely each port will 
still need to specify what the archs of the binary files are, what license 
they're under, what type of distfile it is and where it is, and which files 
inside needs to be copied where.

Re: "cask" ports just keep on rolling in...

[Ken Cunningham]

The idea of MacPorts is to manage installing inter-related libraries and 
executables.

But people want to use it to install prebuilt binaries as well, like homebrew 
does for cask installs.

MP has not decided if it will or will not accept these, but they just keep 
rolling in more and more anyway.

Installing them as "ports" is kinda silly, and wasteful, but simple, practical, 
and slides them in under the radar.

Having an actual plan for these would be better.

If software _can_ be built, we want to do it that way, so (IMHO) your work is 
not wasted. 

We get many benefits, I believe, from building things ourselves.

Whether we do or don't accept binary "cask" installs ins not up to me -- but 
I'm just point out that they are coming in anyway so a plan would be good, esp 
for the multi-megabyte behemoths that are out there.


Ken




On 2021-02-05, at 2:58 PM, Jason Liu wrote:

> The destroot phase needs to — what — record the files that will be installed 
> in some kind of an index file? And also know about the stuff that gets 
> installed into ~/Library, etc.
> 
> You would probably need to get the list of files installed by the installer 
> by running either pkgutil --files or lsbom, if we're talking about a PKG 
> installer. (Or maybe it would be easier to just grab the bom file in its 
> entirety.) Typically running an ls -R on the .app bundle inside a DMG 
> installer would be sufficient for those kinds of installers.
> 
> But then this begs the question: what happens to all of the work that went 
> into the build-from-source packages? Wouldn't this end up rendering the 
> hundreds of hours I spent getting the Blender package to work a complete 
> waste?
> 
> -- 
> Jason Liu
> 
> 
> On Fri, Feb 5, 2021 at 5:31 PM Ken Cunningham 
> mailto:ken.cunningham.web...@gmail.com>> 
> wrote:
> What would we really need to do this properly?
> 
> The current fetch, checksum phases are OK.
> 
> The extract phase can be used as is for some software (simple copies), but 
> for other software we don’t want to extract it, we want to run the installer.
> 
> The configure and build phases need to be overridden and disappear.
> 
> The destroot phase needs to — what — record the files that will be installed 
> in some kind of an index file? And also know about the stuff that gets 
> installed into ~/Library, etc.
> 
> Then run the “cask” destroot without installing any files into the actual 
> destroot:
> 
> copy the apps and stuff
> or 
> run the installer
> or
> extract from the pkg
> or 
> … 
> 
> and then NOT have the entire software repackaged into a MP archive file to be 
> stored 12 different times…
> 
> Or some such plan
> 
> Best,
> 
> Ken
> 
> 
> 
> 
> 
>> On Feb 5, 2021, at 11:00 AM, Ken Cunningham > > wrote:
>> 
>> With no plan, we’ll just keep getting more and more of these.
>> 
>> > >
>> 
>> This kind of port just repackages the DMG into many tgz archives.
>> 
>> It’s wasteful. People want them.
>> 
>> What we should have instead of this is some kinda tech that
>> 
>> 1. downloads the DMG
>> 2. installs the app
>> 3. records some way of uninstalling everything
>> 
>> 
>> What we have instead is a repackaging of the DMG into many, identical, 
>> system-specific archive bundles.
>> 
>> Yuk.
>> 
>> Ken
>> 
> 

Re: "cask" ports just keep on rolling in...

[Jason Liu]

>
> The destroot phase needs to — what — record the files that will be
> installed in some kind of an index file? And also know about the stuff that
> gets installed into ~/Library, etc.
>

You would probably need to get the list of files installed by the installer
by running either pkgutil --files or lsbom, if we're talking about a PKG
installer. (Or maybe it would be easier to just grab the bom file in its
entirety.) Typically running an ls -R on the .app bundle inside a DMG
installer would be sufficient for those kinds of installers.

But then this begs the question: what happens to all of the work that went
into the build-from-source packages? Wouldn't this end up rendering the
hundreds of hours I spent getting the Blender package to work a complete
waste?

-- 
Jason Liu


On Fri, Feb 5, 2021 at 5:31 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> What would we really need to do this properly?
>
> The current fetch, checksum phases are OK.
>
> The extract phase can be used as is for some software (simple copies), but
> for other software we don’t want to extract it, we want to run the
> installer.
>
> The configure and build phases need to be overridden and disappear.
>
> The destroot phase needs to — what — record the files that will be
> installed in some kind of an index file? And also know about the stuff that
> gets installed into ~/Library, etc.
>
> Then run the “cask” destroot without installing any files into the actual
> destroot:
>
> copy the apps and stuff
> or
> run the installer
> or
> extract from the pkg
> or
> …
>
> and then NOT have the entire software repackaged into a MP archive file to
> be stored 12 different times…
>
> Or some such plan
>
> Best,
>
> Ken
>
>
>
>
>
> On Feb 5, 2021, at 11:00 AM, Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
>
> With no plan, we’ll just keep getting more and more of these.
>
> 
>
> This kind of port just repackages the DMG into many tgz archives.
>
> It’s wasteful. People want them.
>
> What we should have instead of this is some kinda tech that
>
> 1. downloads the DMG
> 2. installs the app
> 3. records some way of uninstalling everything
>
>
> What we have instead is a repackaging of the DMG into many, identical,
> system-specific archive bundles.
>
> Yuk.
>
> Ken
>
>
>

Re: "cask" ports just keep on rolling in...

[Ken Cunningham]

What would we really need to do this properly?

The current fetch, checksum phases are OK.

The extract phase can be used as is for some software (simple copies), but for 
other software we don’t want to extract it, we want to run the installer.

The configure and build phases need to be overridden and disappear.

The destroot phase needs to — what — record the files that will be installed in 
some kind of an index file? And also know about the stuff that gets installed 
into ~/Library, etc.

Then run the “cask” destroot without installing any files into the actual 
destroot:

copy the apps and stuff
or 
run the installer
or
extract from the pkg
or 
… 

and then NOT have the entire software repackaged into a MP archive file to be 
stored 12 different times…

Or some such plan

Best,

Ken





> On Feb 5, 2021, at 11:00 AM, Ken Cunningham  
> wrote:
> 
> With no plan, we’ll just keep getting more and more of these.
> 
>  >
> 
> This kind of port just repackages the DMG into many tgz archives.
> 
> It’s wasteful. People want them.
> 
> What we should have instead of this is some kinda tech that
> 
> 1. downloads the DMG
> 2. installs the app
> 3. records some way of uninstalling everything
> 
> 
> What we have instead is a repackaging of the DMG into many, identical, 
> system-specific archive bundles.
> 
> Yuk.
> 
> Ken
> 

Re: "cask" ports just keep on rolling in...

[Blake Garner]

I also think this would be highly desirable. Would it be another portgroup
that needs to be written in tcl?

On Fri, Feb 5, 2021 at 11:01 AM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> With no plan, we’ll just keep getting more and more of these.
>
> 
>
> This kind of port just repackages the DMG into many tgz archives.
>
> It’s wasteful. People want them.
>
> What we should have instead of this is some kinda tech that
>
> 1. downloads the DMG
> 2. installs the app
> 3. records some way of uninstalling everything
>
>
> What we have instead is a repackaging of the DMG into many, identical,
> system-specific archive bundles.
>
> Yuk.
>
> Ken
>
>

"cask" ports just keep on rolling in...

[Ken Cunningham]

With no plan, we’ll just keep getting more and more of these.

>

This kind of port just repackages the DMG into many tgz archives.

It’s wasteful. People want them.

What we should have instead of this is some kinda tech that

1. downloads the DMG
2. installs the app
3. records some way of uninstalling everything


What we have instead is a repackaging of the DMG into many, identical, 
system-specific archive bundles.

Yuk.

Ken

Re: mesa OpenGL header problem with mesa > 17 on SnowLeopard (and older) -- help wanted

[Ken Cunningham]

yes, it's a longstanding issue.

but somwhow it all held together until this last mesa update, and I just can't 
spot why it's broken now.

I have a PR ready to hold back mesa to 17.x ... on < 10.7.

I'll push that later today then...and after thst, wait for divine inspiration.

Ken