I wanted to use cpan2port today for the first time to make a perl
module port. I ran into some problems.
First, I had hoped to find cpan2port in the contrib section of the
repository:
http://trac.macports.org/browser/contrib
but it's not there. I found it on the official site here:
Bradley Giesbrecht wrote:
RPM may be appealing to many for various reasons and I won't
argue that.
Apple has created the package format for distributing binaries
and it is
familiar to most users and does not require any additional
software be
installed.
If macports binaries were
Oh gee. Package management. My favorite subject TEN YEARS
AGO. ;-) /needless-sarcasm
On Mar 23, 2009, at 8:53 PM, Bradley Giesbrecht wrote:
Are uninstall options within a pkg difficult?
Yes. The .pkg format is basically just cpio on a small dose of
steroids. Strictly one-way,
On Tue, Mar 24, 2009 at 2:54 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Mar 23, 2009, at 16:04, C. Florian Ebeling wrote:
Is there a working example of migrating app data to a new format in a
some port? There are obviously a number of issues with doing something
like this:
- finding
Jordan K. Hubbard wrote:
I guess I just don't see the appeal of rpm. What do you see as the
advantages of rpm?
Would rpm be internal to the macports port command and leverage
rpm dependency checking or something?
I think you're asking the wrong question. The right question is
not is
Ryan Schmidt wrote:
Since rosetta doesn't handle ppc64, we can't narrow this down to
a single x86_64 box.
We can't narrow it down to a single Intel Mac per OS anyway
because one of the problems is that some software doesn't cross-
compile correctly. The point is to eliminate the need for
On Mar 24, 2009, at 3:11 AM, Anders F Björklund wrote:
Jordan K. Hubbard wrote:
I guess I just don't see the appeal of rpm. What do you see as the
advantages of rpm?
Would rpm be internal to the macports port command and leverage
rpm dependency checking or something?
I think you're
Jordan K. Hubbard wrote:
I think you're asking the wrong question. The right question is
not is package format foo better than package format bar? but
rather what exactly are we trying to do?
Was it about package formats (.rpm and .deb), or about package
managers (rpm and dpkg) ?
Yes.
Marcus Calhoun-Lopez wrote:
Joshua Root j...@... writes:
Universal, however, should be limited to 32/64-bit universal as soon as
possible.
I see no reason to limit the functionality. Changing the default archs,
sure.
Granted, but the extra functionality comes with a price, especially in
Ryan Schmidt wrote:
It's deprecated if you're running trunk. No warning for 1.7 users.
Right, and I am suggesting that we remove the deprecation warning for
svn.tag from trunk again, and not re-add it until the next version of
MacPorts has been released which includes svn.revision.
Joshua Root j...@... writes:
Once again, I don't believe that the vast majority of users really want
universal, they are just using it as a hack to get x86_64. There may be
a few sharing builds between an i386 and a ppc machine, but they would
be better served by binaries.
If the vast
I was perusing Arch's website today and noticed there's a flag
package out-of-date link when you're viewing information about a
package. Is this something we might find worthwhile for MacPorts
since not everything has a livecheck?
I presume it can put a community-initiated flag of might
Citando Jeremy Lavergne :
I was perusing Arch's website today and noticed there's a flag package
out-of-date link when you're viewing information about a package. Is
this something we might find worthwhile for MacPorts since not everything
has a livecheck?
I presume it can put a
Jeremy Lavergne wrote:
I was perusing Arch's website today and noticed there's a flag package
out-of-date link when you're viewing information about a package. Is
this something we might find worthwhile for MacPorts since not
everything has a livecheck?
I presume it can put a
Sure, there's all kinds of stuff like that that we could do with a
working MPWA/db.macports.org.
What's the status of this thing anyway?
--
Florian Ebeling
Twitter: febeling
florian.ebel...@gmail.com
___
macports-dev mailing list
C. Florian Ebeling wrote:
Sure, there's all kinds of stuff like that that we could do with a
working MPWA/db.macports.org.
What's the status of this thing anyway?
It is on our ideas list for Google Summer of Code this year again, as it
already was last year, but the project failed on the
Were both of those links suppose to be to macports-dev ?
On Mar 24, 2009, at 7:16 PM, MacPorts wrote:
Changed page SummerOfCode by rai...@macports.org from 91.11.216.162*
Page URL: http://trac.macports.org/wiki/SummerOfCode
Diff URL:
Jeremy Lavergne wrote:
Were both of those links suppose to be to macports-dev ?
Of course not, thanks for noticing. Copy and paste error :-)
Fixed now.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Rainer Müller wrote:
I agree that the warning is a bit annoying, and I did not commit the
livecheck.check - livecheck.type rename yet because it is even more
talkative. The deprecation warning there appears for nearly all ports,
each time it is parsed. For example on a dependency walk. I will
Hi folks,
I submitted a port a little over a week ago (http://trac.macports.org/ticket/18870
), but no one has committed it or commented on it yet. No big hurry,
but in someone else's earlier ticket (http://trac.macports.org/ticket/18220
), Rainer suggested that people nudge this list in
On Mar 24, 2009, at 05:26, Anders F Björklund wrote:
While cross-compiling and virtual build machines does have some
entertaining value,
you would probably be better off with one hardware node per OS/arch
and a chroot ?
I'd like that.
Assuming that you're even going to build PowerPC
Rainer Müller wrote:
On 14.03.2009 9:15 Uhr, Neil wrote:
Why not send The following ports are currently installed: to stderr?
Hm, stderr and stdout do not have to be synchron, I am not sure it is a
good idea to mix them for this purpose.
Recently I added a wrapper around isatty(3) which
Ryan Schmidt wrote:
Assuming that you're even going to build PowerPC binaries, it
shouldn't be so hard
finding cheap used hardware for it. The new machines available only
use Intel anyway.
If we want to support universal binaries -- and given the effort
that's been put in so far on
Allen McBride wrote:
I submitted a port a little over a week ago
(http://trac.macports.org/ticket/18870
), but no one has committed it or commented on it yet. No big hurry,
but in someone else's earlier ticket (http://trac.macports.org/ticket/18220
), Rainer suggested that people nudge
On Mar 24, 2009, at 22:47, Rainer Müller wrote:
Ryan Schmidt wrote:
Assuming that you're even going to build PowerPC binaries, it
shouldn't be so hard
finding cheap used hardware for it. The new machines available only
use Intel anyway.
If we want to support universal binaries -- and given
On Mon, Mar 23, 2009 at 3:47 AM, Ryan Schmidt ryandes...@macports.org wrote:
Mac OS X is not Debian. The Mac way is to provide not as many options as
possible, but as few options as possible. Meet the needs of most of the
users with the default setup, and provide a few options for everyone
26 matches
Mail list logo
