<br><br><div class="gmail_quote">On Sat, Dec 17, 2011 at 5:47 AM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tl;dr: I don't know, but isn't it nice that there are now multiple options you can choose from?<br>
<div class="im"><br>
<br>
On Dec 17, 2011, at 02:44, Niels Dettenbach (Syndicat IT&Internet) wrote:<br>
<br>
> But another point here may be - why MacPorts (which is by principe developed and maintained for Mac OS X only) afaik did not cooperate nor participate on well driven / maintained ports projects like pkgsrc?<br>
<br>
<br>
</div>I don't know pkgsrc; I'm not familiar with operating systems other than OS X, really, so I barely know the names of some of the package managers on other operating systems, and know close to zero about how they work internally, nor do I currently have any interest in acquiring that knowledge; I'm focused on OS X.<br>
</blockquote><div><br></div><div>Pkgsrc is the software porting/package system of NetBSD. (They use the term 'package' for software and 'port' to refer to NetBSD hosted on various architectures.) It was derived initially from the FreeBSD port system and, so, has some distant commonality to MacPorts.</div>
<div><br></div><div>The interesting thing about pkgsrc is that it was designed to be portable to multiple POSIX operating systems, not just NetBSD. This includes the various BSD variants, Linux, Solaris, Windows/Interix and, important to us, Darwin/Mac OS X. Details can be found at <a href="http://pkgsrc.org">pkgsrc.org</a>.</div>
<div><br></div><div>I've used pkgsrc a bit on both Panther and Tiger systems. I once asked why it is not spoken in the same breath as MacPorts and Fink- the consensus was "poor advertising".</div><div><br></div>
<div>Numerically, there are more ports, though some are specific to NetBSD on specific platforms. My experiences with building specific ports tended to be mixed. Many went fine, others broke depending on compiler (GCC 3.3 vs. 4.x) and some broke on odd library dependencies or compiler flags. The whole was pretty much what could be expected from a cross-platform environment where the focus is other platforms and a lack of users/testers/developers on this one.</div>
<div><br></div><div>In all fairness, each has its plusses and minuses. In an ideal world, each would probably exist but using a shared knowledge pool of patches and workarounds.</div><div><br></div><div>Going back to the OP's question, I am also curious why one would not run the native packages and package manager if one is available? I run various Linux variants on my other boxes and haven't really hit a case where I'd want a third-party package over the native one.</div>
<div><br></div><div>JR</div><div><br></div><div> </div></div>