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

[Ken Cunningham]

> On Feb 5, 2021, at 10:00 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
> 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.

The last discussion didn’t get anywhere past the appropriate naming scheme :> We never even got into implementation details.

>> 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.
> 

Well, IMHO there is, but I’ve looked at it quite a bit.

Look back a month or so and see my post about a “cask” port for SageMath for an idea of why this won’t work (well) in general.

For trivially simple ports, a few MB or less for a *.app that copies into /Applications/MacPorts — yeah, who cares?

> 
>> 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.

Yes, that would help, if these binary ports start getting to any size.

> 
> 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
> 

Yes. That leverages our existing tools in a nice way. Or a “cask” PortGroup could set “archive_sites” to “” I guess, perhaps more easily.

> 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.
> 

It’s not that it’s too much work. It’s that these things are very simple, and people submit them but don’t know all these details you mention.

And —

this won’t work for larger ports too well (see SageMath message for an extreme example)
we don’t want to run rev-upgrade on them (surprises, surprises, surprises — eg SageMath again)
we want to be able to run a pkg-installer into some destination…. and nobody except three people know how to do that right
we want to be able to uninstall all the cruft the software installs in ~/Library, ~/Preferences, etc easily

So — it’s doable. What we do now is — meh. 

IF we are going to do it, we should do it right.

And — we STILL have no naming scheme, so a user will have NO IDEA if he’s downloading an app from some website on the internet rather than something build by MacPorts.

And I think we should have a good way of identifying them, whatever it is. And yes, I still think identifying them by using a “+prebuilt” variant name is not the way to do it, if for no other reason than that might propagate down through all kinds of ports as “+prebuilt” and nobody wants that, it carries over from installation to upgrade and nobody wants that, and it is not (IMHO) logical to have something specified as “-prebuilt” if there is no “-prebuilt” and on and on and on for why I think this is just not clear enough …

but the NAME is the least of the issues, TBH.

Ken