
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>although I was concerned about getting this pattern right before we had too many of these to fix, it does seem the admins feel there's really no issue to worry about here.</div><div><br></div><div>So I guess we just open the gate and let them in. There is no recommendation for a requirement for a naming convention or other identifier.</div><div><br></div><div>I have gone ahead and committed the ones in the PR queue I found there. Feel free to use those as a template.</div><div><br></div><div>K</div><div><br>On Feb 6, 2021, at 18:16, Mark Anderson <<a href="mailto:mark@macports.org">mark@macports.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Yeah, it seems like a lot of the stuff is in place, but we just need some tweaks. I like the idea of a portgroup like BinaryOnly or something, but what else needs to happen?</div><div><br></div><div>I'd be more than happy to help, what needs to be done? Should we maybe take to Trac to get a to-do and proposal going?</div> <br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>—Mark<br></div><div>_______________________<br>Mark E. Anderson <<a href="mailto:mark@macports.org" target="_blank">mark@macports.org</a>><br></div><div><a href="https://trac.macports.org/wiki/mark" target="_blank">MacPorts Trac WikiPage</a><br></div><div><a href="https://github.com/markemer" target="_blank">GitHub Profile</a><br></div><div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 6, 2021 at 3:28 AM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>

<br>

> On Feb 5, 2021, at 10:00 PM, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>> wrote:<br>

> <br>

> <br>

> <br>

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

> <br>

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

> <br>

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

<br>

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

<br>

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

>> <br>

>> It’s wasteful. People want them.<br>

>> <br>

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

>> <br>

>> 1. downloads the DMG<br>

>> 2. installs the app<br>

>> 3. records some way of uninstalling everything<br>

> <br>

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

> <br>

<br>

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

<br>

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

<br>

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

<br>

> <br>

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

>> <br>

>> Yuk.<br>

> <br>

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

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

<br>

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

<br>

> <br>

> 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. <a href="https://trac.macports.org/ticket/60315" rel="noreferrer" target="_blank">https://trac.macports.org/ticket/60315</a><br>

> <br>

<br>

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

<br>

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

> <br>

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

> <br>

<br>

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

<br>

And —<br>

<br>

this won’t work for larger ports too well (see SageMath message for an extreme example)<br>

we don’t want to run rev-upgrade on them (surprises, surprises, surprises — eg SageMath again)<br>

we want to be able to run a pkg-installer into some destination…. and nobody except three people know how to do that right<br>

we want to be able to uninstall all the cruft the software installs in ~/Library, ~/Preferences, etc easily<br>

<br>

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

<br>

IF we are going to do it, we should do it right.<br>

<br>

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

<br>

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

<br>

but the NAME is the least of the issues, TBH.<br>

<br>

Ken<br>

<br>

<br>

</blockquote></div>

</div></blockquote></body></html>