sshfs for mac version 2.10.0 - make .pkg or .dmg package

tormod_bjorøy wrote:

The sshfs was compiled using meson and ninja. Maybe these tools already have a "pkgutil tool" built in ?

No. They are from a completely different world. However, if you were able to compile something with those tools, then pkgutil should be easy. I have used ninja before. I'm not exaggerating when I say pkgutil is 100 times easier.

If you can give me the commands to run - very specific - Than maybe I will give it a try.

First of all, I was wrong. It isn't pkgutil. That is an older tool. The correct tool to use now is "productbuild". I have no idea about meson or ninja. When I see something like ninja being used, I just take a whole day off and build an Xcode project instead and I'm done with it forever.

Here are instructions I made for someone who was trying to get a notarized, 64-bit build of Ghostscript. In this example, Ghostscript has already been built and installed into the standard location /usr/local. These instructions create a temporary packaging area, copy over all the installed Ghostscript files into the corresponding temp directories, wrap it all into a package, sign, and notarize it. These instructions are a few years old. The "altool" has since been replaced but I'm not familiar with the replacement. I think this should still work though. You will obviously have to adapt it to sshfs, which I'm also pretty unfamiliar with. The different colours are just an artifact of these forums.

# All executables need to be signed with the hardened runtime.
# I am assuming that all these executables have already been built in the project area,
# but not yet installed.
# Obviously, your executable files will be different.
codesign --timestamp --options=runtime -s "Developer ID Application: <your developer id>" -v bin/gs

codesign --timestamp --options=runtime -s "Developer ID Application: <your developer id>" -v bin/pdftoraster

codesign --timestamp --options=runtime -s "Developer ID Application: <your developer id>" -v cups/pstoraster

codesign --timestamp --options=runtime -s "Developer ID Application: <your developer id>" -v cups/pstopxl

# Install into /usr/local
sudo make install

# Copy the installed files into a temporary packaging area
# Again, your files will be different.
sudo mkdir /tmp/ghostscript
ditto /usr/local/bin /tmp/ghostscript/usr/local/bin
ditto /usr/local/share /tmp/ghostscript/usr/local/share
ditto /usr/libexec/cups/filter/pdftoraster /tmp/ghostscript/usr/libexec/cups/filter/
ditto /usr/libexec/cups/filter/pstoraster /tmp/ghostscript/usr/libexec/cups/filter/
ditto /usr/libexec/cups/filter/pstopxl /tmp/ghostscript/usr/libexec/cups/filter/
ditto /private/etc/cups/pdftoraster.convs /tmp/ghostscript/private/etc/cups/
ditto /private/etc/cups/pstoraster.convs /tmp/ghostscript/private/etc/cups/

# Build the installer package
# I went ahead and changed the bundle identifier to something plausible for sshfs just so nobody
# accidentally uses my own bundle identifier.
productbuild --identifier "org.osxfuse.sshfs.pkg" --sign "Developer ID Installer: <your developer id>" --timestamp --root /tmp/ghostscript / sshfs.pkg 

# Apple has a new replacement for the "altool" but I've never used it.
xcrun altool --notarize-app --primary-bundle-id "org.osxfuse.sshfs.pkg" --username "<your apple id>" --password "<your app-specific password>" --file sshfs.pkg

# Hopefully the notarization happens quickly. You may have to do this a couple of
# of times until it goes through. Or just wait for the e-mail from Apple.
xcrun altool --notarization-history 0 -u "<your apple id>" -p "<your app-specific password>"

# After the notarization is successful, you can staple.
xcrun stapler staple sshfs.pkg

tormod_bjorøy wrote:

Thanks for the reply !

I don´t currently have an apple developer id.

Would it be wise to get my own developer id, or should I ask the person who distrubute

sshfs for mac (2.5.0) to use his apple ID number ? Version 2.5.0 is from feb 2014.

I don´t see any benefits from trying to distribute this under my own developer ID.

I would think it wise to have your own Developer ID here, as you’re headed for maintainer here, possibly with your own github account.

But that’s between you two to decide.

Many developers can be understandably a little leery about signing and distributing code for others, or having others sign their code, though.

But if this is a case of “throw it over the wall”, I wouldn’t sign it, nor spend much effort on packaging it.

tormod_bjorøy wrote:

This is about sshfs for mac.

I would expect that this github program has high traffic and is downloaded every day by a lot of people.

sshfs is used by universities, research, organizations etc etc....

Yes. I know. I was a very heavy user of sshfs about a decade ago. At one point, I even tried to write my own Mac App Store version. I was successful, but I discovered that Apple's WebDAV layer, which I was using for local interconnections, was not reliable.

Menson and ninja was selected for the Linux version

I know. My question is why? It's two files. One shell script - two lines long - will do the trick.

Assist in what way? Have you tried the pkgutil tool?

Sorry. I don't have an answer for you. Anyone who is distributing Mac software should have a Developer account. That's not negotiable. Whether or not you want to sign someone else's code with it is a different question.

If I were doing this for someone else, I would verify that everything was working, write it up in a script, and then give it to the maintainer to be distributed under the project's official Developer ID.

But if no one involved is willing to spend $99, then it is all a moot point. If that is the case, why do you even care about the pkg anyway? The whole purpose of such a file is to be easy to distribute and install. But if no one involved wants to do what is necessary to make the software easy to distribute and install, then why make any effort to make the software easy to distribute and install. It's a catch-22, isn't it?

If the big issue is that meson and ninja are too difficult for mere mortals to build, that would be a valid reason to use a pkg. But then you need to honestly ask why meson and ninja were selected for this project in the first place. I mean really, the thing has a grand total of 2 C files. Furthermore, I would be highly suspicious of those "compat" files for OS X that are 16 years old.

There is a reason why these open source projects wither on the vine and die.