> On Feb 5, 2021, at 10:00 PM, Ryan Schmidt <[email protected]> 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
