Daniel wrote:
> we try not to actively break the use of MacPorts on non Mac OS X systems
Just how many users does MacPorts have on these non-Mac-OS-X systems?
The fact that no one seems to know if kaffe even works in any meaningful way
(it almost certainly doesn't) seems to indicate that the num
Anders F Björklund wrote:
>> The previous +system_x11 variant did this, it would use $x11prefix
>> (/usr/X11R6 or /usr/X11 depending on your system version) rather than
>> install new ports in $prefix (for xorg).
and Ryan Schmidt replied:
> Right. And so many issues occurred as a result that it
For some (unrelated-to-macports) research I've been doing, I've been looking at
various graph metrics, and so I figured it might be interesting to show some
metrics for MacPorts ports.
Top fifty most required ports:
ncursesw, ncurses, gperf, libiconv, zlib, expat, gettext, perl5.12,
op
Anders F Björklund wrote:
>>> Because what the Mac really needed was yet another packaging solution. How
>>> many is that now?
>>
>> I'm counting 4 or so. Most of which doesn't have any packages available!
>> That would be MacPorts (port), Fink (fink), Homebrew (brew) and my RPMS.
>
> Almost fo
Ryan Schmidt wrote:
> Sorry, you're right of course. I guess I was thinking of some other utilities
> on Mac OS X, like sed, which are BSD versions, whereas Linux typically has
> GNU versions, and this difference can sometimes affect ports.
FWIW, as much as possible, I believe that if something
Ryan Schmidt wrote:
> Mac OS X (well, Xcode) has BSD make.
Uh, no -- at least not the way you seem to be thinking.
% /usr/bin/make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not ev
In the course of plotting the MacPorts dependency graph for my own edification,
I discovered that there are some ports that have incorrect dependencies (i.e.,
they depend on ports that don't exist). For the most part, these appear to be
typos or name changes that were not updated everywhere.
T
Joshua Root wrote:
> I agree the FAQ entry could do with a rewrite to use less dismissive
> language. Patches welcome. ;-)
I don't think you want a patch from me. I'd replace it with the following
attempt at humor:
;-)
MacPorts is a bit like a cult. You need to really commit it it. One day,
Jonathan Stickel wrote:
> I think what you are asking for is the intent of "Homewbrew":
>
> http://mxcl.github.com/homebrew/
>
> Now, I have only read about Homebrew and haven't tried to use it, but I can
> imagine all kinds of gotchas that might arise.
Because what the Mac really needed
Joshua Root wrote:
> You might just have 'macportsuser root' in your macports.conf.
Here's what I have:
% grep macportsuser /opt/local/etc/macports/*
/opt/local/etc/macports/macports.conf.default:#macportsuser macports
% grep macportsuser ~/.macports/*
(nothing)
Also, according to D
On Aug 16, 2011, at 15:27, Dan Ports wrote:
>>> [Speaking of which, I would think we should stop doing that; Java has been
>>> part of the base OS for years and I would be surprised if all of our Java
>>> ports really work with Kaffe instead. Does Kaffe itself even work nowadays?]
and Ryan Schmi
Joshua Root wrote:
> The archives are accompanied by a signed hash; that's the .rmd160 file you
> might have noticed. Port won't install a downloaded archive if the signature
> can't be verified.
I did see the rmd160 files, but assumed from the name that they were merely
hashes (and as 512-byte
Ryan wrote:
> FYI, in case you made that diagram by hand, we also have the port-depgraph
> script to generate things:
>
> https://trac.macports.org/browser/contrib/port-depgraph
>
> And also the depTree.py script which works similarly:
>
> https://trac.macports.org/browser/users/ebo
Jeremy Lavergne wrote:
>> If MacPorts didn't have a propensity to compile everything from source
>
> It doesn't do that by default anymore.
Strange, because when I look at
http://packages.macports.org/pcre/
I find no packages for darwin11 (and no ppc packages either), and when I look at
Daniel J. Luke wrote:
>> see https://trac.macports.org/wiki/FAQ#ownlibs
... and Dan Ports replied:
> FWIW, I find that FAQ answer really unsatisfying. I agree that there are good
> reasons why MacPorts uses its own libraries, but the claim that "the
> drawbacks of this policy are minimal" just s
Many MacPorts packages depend on other MacPorts packages of software that
already exists on a Mac OS X system, such as
perl5
bison
m4
openssl
bzip2
zip
ncurses
and so on. I realize that some users may want to run the latest and greatest
ve
16 matches
Mail list logo
