No subject

snapd working on Mac (which might need some patching), but not in the
sense of replacing the binary format because =E2=80=93 as others pointed ou=
t =E2=80=93
there is no way that other Mac users would be able to fetch a binary
package from MacPorts server and run it on their computer anyway.

On top of that, snapd also means a different format of source
packages. Replacing tcl with yaml is not realistic any any short
period of time (short of "restarting" the whole MacPorts project).

And all snapd packages are currently *hosted* at some Canonical server
which is not realistic for OS X packages.

So basically we *could* explore whether we could come up with something lik=
e
    sudo port install snapd
that would be able to create and install packages. But we would likely
also have to set up our own server.

I checked

> file something.snap
something.snap: Squashfs filesystem, little endian, version 4.0,
232332336 bytes, 6014 inodes, blocksize: 131072 bytes, created: ...

for a random snap from their store, but didn't investigate any further
yet to see what and how they actually pack inside that format. What
I'm most interested in is how they handle dependencies (on Qt etc.)
and how they handle different versions of libraries.

Apple solved most of this problems for packages in the self-contained
.app format (heavily criticised by some Linux users/devs, explaining
how inefficient it is to provide a zillion copies of Qt), but:
- they are horribly difficult to create when many dependencies are needed
- I still believe that we are missing some nice "package manager"
devoted to making .app

Consider the huge amount of effort that went into creating patches for
different libraries, so that they work on OS X (even if the upstream
never tested them on OS X) and none of that gets used when creating
packages (or has to be manually integrated). I would absolutely *love*
to be able to install MacPorts (or HomeBrew or snap or anything else
for that matter) and create a port/package where I would list the
dependencies and then make a package that would automatically generate
a self-contained .app.

MacPorts has to keep reminding software authors to stop shipping
software that installs something in /opt/local (because using MacPorts
was the least painful way for them to install dependencies which they
kept at default locations).

Snap could (perhaps?) offer a solution for that, I don't know.

It is certainly worth looking into, but not as a *replacement* for
Portfiles and binary archive. (At least not for now.)

Mojca