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 <rjvber...@gmail.com>: > > Morning! > > 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): > > http://github.com/RJVB/lnxports > > and the regular repository: http://github.com/RJVB/macstrop > > R. > _______________________________________________ > macports-users mailing list > macports-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
