snapd

[Sterling Smith]

As long as we are on the topic of other package managers, about a year ago I switched to conda (http://conda.pydata.org/docs/intro.html) on linux for managing python and underlying c/fortran dependencies.  I wondered if any MacPorts developers had pursued conda on Mac with any success.  There is a section in the "Building Packages" section about Linux vs OSX libraries and the need for patchelf or install_name_tool to fix those.  

Thanks,
Sterling

On Jun 17, 2016, at 11:00PM, Mojca Miklavec <mojca at macports.org> wrote:

> 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 at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev