pet project : LnxPorts
Sven Kolja Heinemann
web at bachsau.name
Wed Oct 7 11:36:24 PDT 2015
If your Linux Distribution does not provide latest packages, you can either install them from 3rd party repositories or try another distribution like Arch Linux or Gentoo, or compile them from upstream using the userland of your distribution.
MacPorts exists to make OS X a complete BSD distribution, because its missing a package manager and optional components. I don't see why anyone would install something like this on a Linux distribution that already has a fully featured package manager. It would just make things more complicated.
> Am 07.10.2015 um 19:59 schrieb René J.V. Bertin <rjvbertin at gmail.com>:
> OK now, don't get me wrong, this is not an announcement that I'll be forking off MacPorts to begin a fully supported Linux variant! :)
> However, if anyone on here is like me (a developer's not to say hacker's mindset, and swinging back and forth between the OS X and Linux household members), they might see the use for being able to install select ports through a familiar and well-tested package/distribution system without interfering with the host.
> Reasons this tempts *me* include MacPorts' de/activation feature, the fact that I've come to know its inner workings much more intimately than I probably should, but above all the fact I'm running a LTS version (KUbuntu 14.04) which means I don't always get the latest updates for things that are not security-related. Probably because DebUntu's packaging system can make it very complicated if not impossible to update individual packages that are "sitting in the midst of an interdependency web". For other packages it can be a b*tch to update the packaging scripts to accommodate a (much) newer version so that a build bot (PPA) can build and serve them as a personalised system update.
> One such "package" would be Qt5; Ubuntu gives us 5.2.1 and even though Qt guarantees that I could update to 5.5.0 with full backwards compatibility it's just too much work to do this via a PPA. Enter the qt5 ports I've been working on for about 6 months now. My Linux desktop isn't Qt5-based, so I can make do with a (more) recent Qt5 installed in a prefix like /opt/local .
> I had already built a few of the ports I (co)maintain on Linux, so it was easy enough to decide to see if Qt5 would build. There was the issue of the much larger amount of dependencies, though, so I decided to test an approach that relaxes MacPorts reproducible-build principle considerably. Did I say my Linux netbook is *slow*? Rather than forcing "internal" dependencies, I'd see how far I'd come using dependencies from the host.
> A lot of that is handled through platform-specific depends_* declarations in the Portfile, but I also tweaked the pkgconfig port. Basically, I let port:pkgconfig install (through a Linux-specific variant) /opt/local/bin/pkgconfig that is in fact a shell wrapper that calls /usr/bin/pkgconfig after setting the environment such the command will look first in MacPorts' pkg-config database before looking in the system database.
> With that, very little further modifications (but lots of patience) were needed to get my port:qt5-kde to build under Linux. And it works just peachy.
> So for anyone still with me and interested by the above, I'm now maintaining an additional port repository for Linux (which should come before my regular port repository in /opt/local/etc/macports/sources.conf):
> and the regular repository: http://github.com/RJVB/macstrop
> macports-users mailing list
> macports-users at lists.macosforge.org
More information about the macports-users