On Aug 28, 2011, at 11:46 AM, Bradley Giesbrecht wrote:
>
> On Aug 28, 2011, at 8:25 AM, Anders F Björklund wrote:
>
>> Bradley Giesbrecht wrote:
>>
> I do my building on a single machine and rsync out the /opt/local/
> results to my clients. I have always considered it a great design
On Aug 28, 2011, at 8:25 AM, Anders F Björklund wrote:
> Bradley Giesbrecht wrote:
>
I do my building on a single machine and rsync out the /opt/local/ results
to my clients. I have always considered it a great design and I want to
encourage maintaining the /opt/local/. If thing
Bradley Giesbrecht wrote:
>>> I do my building on a single machine and rsync out the /opt/local/ results
>>> to my clients. I have always considered it a great design and I want to
>>> encourage maintaining the /opt/local/. If things were built and spread out
>>> across the file tree my methods
On Aug 28, 2011, at 5:41 AM, Anders F Björklund wrote:
> Ben Greenfield wrote:
>
>> Hey All,
>>
>> I have been using MacPorts for years and the way I use it works because of
>> /opt/local/. If the notion of everything living under /opt/local went away
>> I would have to change my process.
Ben Greenfield wrote:
> Hey All,
>
> I have been using MacPorts for years and the way I use it works because of
> /opt/local/. If the notion of everything living under /opt/local went away
> I would have to change my process.
I don't think anyone has suggested this.
> I do my building on a
Hey All,
I have been using MacPorts for years and the way I use it works because of
/opt/local/. If the notion of everything living under /opt/local went away I
would have to change my process.
I do my building on a single machine and rsync out the /opt/local/ results to
my clients. I have
Ryan Schmidt wrote:
>> You could add a different ports tree (or several actually, one for each OS)
>> like the original poster did with his ports. That's maybe not another
>> globally confusing flag like +universal or +system_x11, but still something
>> of a "fork" of the ports ? But I always t
On Aug 27, 2011, at 04:55, Anders F Björklund wrote:
> Jordan K. Hubbard wrote:
>
>> On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:
>>
>>> And I think we all know that Apple prides itself on producing software that
>>> has *few* options. Apple does *not* add an option to iTunes or iOS just
Titus von Boxberg wrote:
>> Unless somebody completes Pallet, the only working GUI would be Port
>> Authority. And that is still too technical for most users, since they don't
>> want to hear about ports/packages but about apps/software. With icons. Big
>> icons. So it would need something mor
Rainer Müller wrote:
> On 2011-08-27 12:26 , Anders F Björklund wrote:
>> This sounds like the discussion about using /usr/local for prefix ?
>> (rather than the /opt/local, which everybody confuses with /opt ...)
>> It's even more fun, since it's in the default search paths and thus
>> will affec
Am 27.08.2011 um 11:55 schrieb Anders F Björklund:
>>
>> I guess, then, that this is really an appeal to hide the details since you
>> can only get away with doing things "the Apple way" if you also hide the
>> majority of the working parts from the end-user. In MacPorts' case, this
>> would
On 2011-08-27 12:26 , Anders F Björklund wrote:
> This sounds like the discussion about using /usr/local for prefix ?
> (rather than the /opt/local, which everybody confuses with /opt ...)
> It's even more fun, since it's in the default search paths and thus
> will affect most things afterwards - e
Ryan Schmidt wrote:
> Right now, we know that MacPorts works, when pulling in all these
> dependencies people in this thread are so keen to remove. We could spend a
> lot of effort changing a lot of ports to use system dependencies, and find
> that it doesn't work for a bunch of ports, and we'v
Jordan K. Hubbard wrote:
> On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:
>
>> And I think we all know that Apple prides itself on producing software that
>> has *few* options. Apple does *not* add an option to iTunes or iOS just
>> because one power user thinks it might be fun to play with.
On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:
> And I think we all know that Apple prides itself on producing software that
> has *few* options. Apple does *not* add an option to iTunes or iOS just
> because one power user thinks it might be fun to play with. Apple provides
> default funct
On Aug 20, 2011, at 21:30, Joshua Root wrote:
> On 2011-8-20 06:07 , Jordan K. Hubbard wrote:
>>
>> Time for a re-think, or
>> perhaps even just the creation of some sort of modality such that those
>> who wish to live on the risky edge can set a switch (and advance
>> apologies if that switch al
On 2011-8-20 06:07 , Jordan K. Hubbard wrote:
>
> Time for a re-think, or
> perhaps even just the creation of some sort of modality such that those
> who wish to live on the risky edge can set a switch (and advance
> apologies if that switch already exists and I simply haven't noticed it
> yet) an
Jordan K. Hubbard wrote:
> That said, they're definitely using the MacPorts decision to "go heavy" (and
> controlled) vs "go light" against it in a fairly major way, which relates
> back to the question I just asked: Time for a re-think, or perhaps even just
> the creation of some sort of moda
On Aug 16, 2011, at 1:44 PM, 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.
That motiv
On Aug 16, 2011, at 12:23 PM, M.E. O'Neill wrote:
> Many MacPorts packages depend on other MacPorts packages of software that
> already exists on a Mac OS X system, such as
Thanks for bringing this up! I think it's a very valid point.
Another related and equally valid point is that a lot of
On 08/17/2011 03:44 AM, Anders F Björklund wrote:
Ryan Schmidt wrote:
Maybe you could provide more detail (or pointers) about the problems that
occurred? In my experience, there are quite a number of things that can go
wrong in the MacPorts model of variants/installed/activated, but as I
un
On Aug 17, 2011, at 07:29, Anders F Björklund wrote:
> Right, I just meant that the supported CPU itself is only x86_64.
> There's still i386 support, not to worry. Just no PowerPC/Rosetta.
>
> But if building a binary for a regular program, there is no need
> for a i386 version unless there are
On Aug 17, 2011, at 2:15 PM, M.E. O'Neill wrote:
>
> 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 wa
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
On Aug 16, 2011, at 4:27 PM, 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?]
we try not to a
On Aug 16, 2011, at 2:50 PM, Dan Ports wrote:
>
> It may well be true that we are, on the whole, better off for building
> these dependencies, but we shouldn't dismiss the cost of doing so.
The main cost (IMHO) is the build time - and people are working on making that
not really an issue (since
On Aug 16, 2011, at 5:01 PM, Anders F Björklund wrote:
>
> Daniel J. Luke wrote:
>
>> Few people probably remember this, but back when I started using MacPorts,
>> one of the selling points was that it used the built-in MacOS X software (as
>> opposed to fink, which installed its own versions o
On Aug 17, 2011, at 10:18, bradley newton haug wrote:
>
> On Aug 16, 2011, at 3:51 PM, Ryan Schmidt wrote:
>
>> According to the comment in the ghc portfile, only Perl 5.8 is usable. I
>> don't understand the details of why.
>>
>> The ghc port is rather out of date. Unfortunately our ghc main
On Aug 16, 2011, at 3:51 PM, Ryan Schmidt wrote:
>>
>
> According to the comment in the ghc portfile, only Perl 5.8 is usable. I
> don't understand the details of why.
>
> The ghc port is rather out of date. Unfortunately our ghc maintainer has not
> been very active in recent years. If some
Ryan Schmidt wrote:
>> Fortunately Mac OS X has universal binaries, so it has it easier and
>> of course there's only x86_64 in Lion anyway so that's also "easy". :-)
>
> Surely not? I know Lion only runs on x86_64 processors, but surely we can
> still compile things for i386 on it? We have many
On Aug 17, 2011, at 05:05, Anders F Björklund wrote:
> Fortunately Mac OS X has universal binaries, so it has it easier and
> of course there's only x86_64 in Lion anyway so that's also "easy". :-)
Surely not? I know Lion only runs on x86_64 processors, but surely we can still
compile things fo
Ryan Schmidt wrote:
>> Maybe you could provide more detail (or pointers) about the problems that
>> occurred? In my experience, there are quite a number of things that can go
>> wrong in the MacPorts model of variants/installed/activated, but as I
>> understand it, those fundamentals have stay
On Aug 17, 2011, at 05:02, M.E. O'Neill wrote:
> 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:
M.E. O'Neill 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
M.E. O'Neill 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
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
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
>> 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 forgot GTK-OSX (jhbuild) and my new b
On Aug 17, 2011, at 03:36, Anders F Björklund wrote:
> M.E. O'Neill wrote:
>
>> One of the strengths of MacPorts is its variants system. It doesn't seem
>> unreasonable to me to have a +systemlibs variant that as much as possible
>> tries to use the system libraries, at least for things that d
M.E. O'Neill wrote:
> 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.
>
> Bec
M.E. O'Neill wrote:
>> [using kaffe] won't actually happen. swig-java depends on kaffe, but if you
>> look into the swig portgroup you'll see this is declared as
>> "bin:java:kaffe". Which means the dependencies installed by swig-java are
>> in fact much more reasonable
>
> Well, that's good,
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,
On Aug 16, 2011, at 18:55, M.E. O'Neill wrote:
> I suspect it'll be much the way it is with Flash now -- Apple used to provide
> it, now you have to go to Adobe to download it. (Or maybe MacPorts has
> ambitions to provide GNU Gnash as the system flash player too.)
I actually started looking
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
On Aug 16, 2011, at 17:52, M.E. O'Neill wrote:
> 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 packag
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 2011-8-17 09:46 , M.E. O'Neill wrote:
> Joshua Root wrote:
>> The buildslave uses a MacPorts install with mostly default settings, which
>> means the build phase is run as the 'macports' user.
>
> I suppose I should junk my much-upgraded MacPorts install and start over if
> that's the way it'
On Aug 16, 2011, at 4:09 PM, Joshua Root wrote:
> On 2011-8-17 06:27 , Dan Ports wrote:
>> In this case, it isn't nearly as bad as that graph suggests. Nearly all
>> of those dependencies are needed only for kaffe, which is only installed
>> on systems where Java isn't already available.
>>
>> [
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
On Wed, Aug 17, 2011 at 09:09:25AM +1000, Joshua Root wrote:
> Lion is the beginning of the end for Apple-supplied Java. So maybe we'll
> need our own again soon.
...but hopefully it won't be Kaffe, which hasn't been updated in
years.
Dan
--
Dan R. K. Ports MIT CSAIL
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
On 2011-8-17 06:27 , Dan Ports wrote:
> In this case, it isn't nearly as bad as that graph suggests. Nearly all
> of those dependencies are needed only for kaffe, which is only installed
> on systems where Java isn't already available.
>
> [Speaking of which, I would think we should stop doing tha
On 2011-8-17 08:52 , M.E. O'Neill wrote:
> 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 da
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?]
The ability to run
> I find no packages for darwin11
>
> And those binary packages, who builds them? Are they signed? Are we still
> building packages as root?
So really the complaint is that nothing is yet pre-built for Lion--we have a
GSoC project that will give us a very good picture of what the majority of
On 2011-8-17 08:51 , Ryan Schmidt wrote:
>
> MacPorts 2.0.0 introduced our buildbot and installing from binaries. We
> (primarily Joshua!) are still sorting through the ports that the builtbot is
> failing to build, and fixing them, so over time, more and more ports should
> be available as qui
On Tue, Aug 16, 2011 at 03:08:31PM -0700, M.E. O'Neill wrote:
> I summarized my feelings about swig's dependencies with this diagram:
>
> http://i.imgur.com/S6vyf.png
I certainly take your point re: dependencies; I think it's a problem in
general.
It's easy for ports to accumulate depende
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
On Aug 16, 2011, at 17:08, M.E. O'Neill wrote:
> I summarized my feelings about swig's dependencies with this diagram:
>
> http://i.imgur.com/S6vyf.png
FYI, in case you made that diagram by hand, we also have the port-depgraph
script to generate things:
https://trac.macports.org/browser
On 2011-8-17 08:08 , M.E. O'Neill wrote:
> 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 "t
> If MacPorts didn't have a propensity to compile everything from source
It doesn't do that by default anymore.
> megabytes do matter when some people need to pay for bandwidth (e.g., over a
> 3G connection).
Your development machine lives on a 3G connection?
smime.p7s
Description: S/MIME cr
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
On Tue, Aug 16, 2011 at 03:29:38PM -0400, Daniel J. Luke wrote:
> see https://trac.macports.org/wiki/FAQ#ownlibs
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"
Daniel J. Luke wrote:
> Few people probably remember this, but back when I started using MacPorts,
> one of the selling points was that it used the built-in MacOS X software (as
> opposed to fink, which installed its own versions of everything).
As I remember it, it was quite the other way arou
On Aug 16, 2011, at 4:44 PM, Jonathan Stickel wrote:
>
> On 8/16/11 13:23 , M.E. O'Neill wrote:
>> By default, swig has build dependences on bison and gsed. Yet swig
>> builds fine on stock OS X, so special versions of bison and gsed
>> are*NOT* required. If I remove these build dependences by
On 8/16/11 13:23 , M.E. O'Neill wrote:
By default, swig has build dependences on bison and gsed. Yet swig
builds fine on stock OS X, so special versions of bison and gsed
are*NOT* required. If I remove these build dependences by hand (and
remove the line that edits the configure script to use
On 2011-8-17 05:23 , M.E. O'Neill wrote:
> By default, swig has build dependences on bison and gsed. Yet swig builds
> fine on stock OS X, so special versions of bison and gsed are *NOT* required.
> If I remove these build dependences by hand (and remove the line that edits
> the configure scr
> So, please consider this a plea to give users like me a way to just
> install the software we actually want and rely as much as possible on what
> is already there and working quite-well-enough-thank-you on the system.
If the packages available on the system aren't all the same architecture
(and
On Aug 16, 2011, at 3:23 PM, M.E. O'Neill wrote:
>
> Many MacPorts packages depend on other MacPorts packages of software that
> already exists on a Mac OS X system,
yep.
see https://trac.macports.org/wiki/FAQ#ownlibs
--
Daniel J. Luke
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
71 matches
Mail list logo
