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 <mo...@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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
