On 17 June 2016 at 18:32, Ryan Schmidt wrote:
>
> On Jun 17, 2016, at 11:24 AM, Alexey Kuznetsov wrote:
>
>> Universal “snap” packages launch on multiple Linux distros
>>
>> https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
>>
>> Even OpenWRT on the list. Why not join?
>
> Do I understand correctly that you are suggesting that MacPorts should change
> its binary package format from what it currently uses to this "snap" package
> format? If so, what would be the advantage to MacPorts to doing so?
Maybe I misunderstand the concept (I only spent a few minutes reading
the page) and I'm actually amazed that they finally came up with this,
something that's compatible across different linux distribution (which
is something that's been "killing" linux for a long time). This looks
as if Linux finally has some good chances to actually get quality
software (including commercial packages) delivered to all distros.
But from what I understand, snapd doesn't *replace* the main package
manager anywhere, but rather *complements it*. This looks like a
package manager on its own, more like an "App Store" from where one
can download various software that neither depends nor conflicts with
anything installed by MacPorts, and one can easily live with software
X installed by both MacPorts and App Store.
To greatly simplify it, it's like doing
sudo port install py35-pip
pip-3.5 install <some-python-package>
or
sudo port install perl5.24
cpan install ...
and get access to numerous python/perl/whatever packages that only had
to be prepared once and work everywhere, on each platform, on each OS,
... (except that snap seems to provide binaries rather than sources).
From that perspective it might be worth exploring whether we could get
snapd working on Mac (which might need some patching), but not in the
sense of replacing the binary format because – as others pointed out –
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 like
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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
