"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 <ken.cunningham.webuse at gmail.com <mailto:ken.cunningham.webuse at 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.webuse at gmail.com <mailto:ken.cunningham.webuse at gmail.com>> wrote:
>> 
>> With no plan, we’ll just keep getting more and more of these.
>> 
>> <https://github.com/macports/macports-ports/pull/9936 <https://github.com/macports/macports-ports/pull/9936>>
>> 
>> 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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210205/31334f34/attachment.htm>