Currently there is support for PKG (mdmg) and RPM (4.4) and XPKG
(sortof)
To install them, one would use Installer.app or rpm or xpkg as
appropriate.
It should be noted that there is support for "flat" packages (.pkg)
and for RPM 5.0 (.rpm) as well as the earlier versions listed above.
-
Joshua Root wrote:
So sticking with the archives seemed like a reasonable approach.
I do think archives should be the short-term goal. The true binary
distro utopia Jordan describes will naturally be a lot more work.
That is what I figured, so any packages will have to be external "for
now
Anders F Björklund wrote:
> Joshua Root:
>
>>> But then it went from there (we're busy), to "MacPorts is a source
>>> distribution".
>>
>> "MacPorts is a source distribution" is merely a statement of fact, not
>> of policy, as far as portmgr is concerned.
>
> Okay, I heard more like "we don't nee
Joshua Root:
But then it went from there (we're busy), to "MacPorts is a source
distribution".
"MacPorts is a source distribution" is merely a statement of fact, not
of policy, as far as portmgr is concerned.
Okay, I heard more like "we don't need no steenking packages"...
So sticking with
Anders F Björklund wrote:
> Jordan K. Hubbard wrote:
>
>> I could easily see the MacPorts project saying, in some collective
>> consciousness fashion: "Hey, we nearly died and came back to life! We
>> have a lot more ports than we ever did before, a lot of them even work
>> now, so hey, what the
Jordan K. Hubbard wrote:
I could easily see the MacPorts project saying, in some collective
consciousness fashion: "Hey, we nearly died and came back to life!
We have a lot more ports than we ever did before, a lot of them
even work now, so hey, what the hell do you want, BLOOD? Go peddl
On Mar 28, 2009, at 5:10 PM, Jeff Johnson wrote:
I'm saying that you were largely honking the same Newer! Better!
Bestest!
themes 5+ years ago.
Hurm. If that was your take-away from this, then I somehow
*seriously* failed to make my point, both 5+ years ago and now. I am
not asking, n
On Mar 28, 2009, at 8:03 PM, Jordan K. Hubbard wrote:
So, in order to "grant my wish", you're saying that you have also
accepted the Religion Of The Four Criteria into your heart and will
next start contributing some MacPorts code to accomplish this?
Huzzah! I can hardly wait! :-)
N
On Mar 28, 2009, at 12:55 PM, Jeff Johnson wrote:
My definition of "completed" from the perspective of "Packages
delivered by the MacPorts project using some hardware that Apple
donated for the purpose" would be:
I see. So the 2700+ packages I built from darwinports on several
occaisio
Jordan K. Hubbard wrote:
This would still require someone to choose/write the "pkg" program,
and then make all invocations of "install" go through this layer...
Yep! That's the basic idea.
Unfortunately choosing an existing program (such as rpm) means that
it isn't optimally built for the
On Mar 28, 2009, at 3:44 PM, Jordan K. Hubbard wrote:
On Mar 28, 2009, at 12:16 PM, Jeff Johnson wrote:
On Mar 28, 2009, at 2:59 PM, Jordan K. Hubbard wrote:
I don't know if "popular" would be the word I would use. Neither
solution has ever actually been *completed* would be a more
On Mar 28, 2009, at 12:16 PM, Jeff Johnson wrote:
On Mar 28, 2009, at 2:59 PM, Jordan K. Hubbard wrote:
I don't know if "popular" would be the word I would use. Neither
solution has ever actually been *completed* would be a more
accurate statement, so the resulting popularity of said
On Mar 28, 2009, at 2:59 PM, Jordan K. Hubbard wrote:
I don't know if "popular" would be the word I would use. Neither
solution has ever actually been *completed* would be a more accurate
statement, so the resulting popularity of said solution is
impossible to gauge. The MacPorts proj
On Mar 28, 2009, at 5:21 AM, Anders F Björklund wrote:
Jordan K. Hubbard wrote:
It would be nice[er] IMO if a solution could be devised which makes
"port install foo" and "pkg install file:///foo.xar" lead to
exactly the same place. Well, to be even more precise, it would be
nicer still
Jordan K. Hubbard wrote:
It would be nice[er] IMO if a solution could be devised which makes
"port install foo" and "pkg install file:///foo.xar" lead to
exactly the same place. Well, to be even more precise, it would be
nicer still if "port install foo" simply became a wrapper around
"p
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 t
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 s
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 bina
Joshua Root 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 majority of
Marcus Calhoun-Lopez wrote:
> Joshua Root 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 i
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) ?
Y
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 askin
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 c
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 pac
Oh gee. Package management. My favorite subject TEN YEARS
AGO. ;-)
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, and the pre/post-f
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 package
On Mon, Mar 23, 2009 at 21:45, Marcus Calhoun-Lopez
wrote:
> Granted, but the extra functionality comes with a price, especially in
> Portfile creation and maintenance.
> It also adds the problem of dependencies.
> Now, if one port depends on another, then not only must they both be
> universal, t
Joshua Root 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
Portfile creation and maintenan
On Mar 23, 2009, at 8:25 PM, Joshua Root wrote:
Bradley Giesbrecht wrote:
On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
[...]
We could also resume building RPMS, if someone wants to spend
some time on that. The build script could probably produce both
archives and packages in the sa
On Mar 23, 2009, at 22:25, Jeremy Huddleston wrote:
On Mar 23, 2009, at 18:43, 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 sof
On Mar 23, 2009, at 18:43, 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
Bradley Giesbrecht wrote:
>
> On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
> [...]
>> We could also resume building RPMS, if someone wants to spend
>> some time on that. The build script could probably produce both
>> archives and packages in the same run, from the same destroot.
>
>
>
Marcus Calhoun-Lopez wrote:
> I am all for binary builds, but I would suggest that work on
> universal variants continue (personally I find them very useful).
It is useful to be able to build universal, but universal *variants* are
the wrong way of going about it.
> Universal, however, should be
On Mar 23, 2009, at 3:50 PM, Anders F Björklund wrote:
[...]
We could also resume building RPMS, if someone wants to spend
some time on that. The build script could probably produce both
archives and packages in the same run, from the same destroot.
RPM may be appealing to many for various re
Ryan Schmidt writes:
> I'm getting really burned out on universal.
...
>
> The new muniversal portgroup aims to solve this but has other severe
> problems, in that the configure phase runs once for each
> architecture, and some configure scripts are written wrong so they
> try to run a pro
On Mar 23, 2009, at 18:01, Jeremy Huddleston wrote:
On Mar 23, 2009, at 15:12, Ryan Schmidt wrote:
I would want (at least) one build server for each OS and processor
combination, but if we began with just a single Intel Leopard
machine, that would cover the majority of users. If we add a
On Mar 23, 2009, at 15:12, Ryan Schmidt wrote:
I would want (at least) one build server for each OS and processor
combination, but if we began with just a single Intel Leopard
machine, that would cover the majority of users. If we add a
corresponding PowerPC Leopard machine, then we could
Ryan Schmidt wrote:
Despite the fact that they cover much more than "just"
universal (arch) and configure (autotools), that is...
So it's more of a legacy quirk, than a design decision.
I'm getting really burned out on universal.
It sorta worked originally, but has probably outlived itself.
On Mar 23, 2009, at 05:47, Anders F Björklund wrote:
The +universal "variant" is a glorious mess that mixes all
of fatness (universalness, archness, whatever...) and
MDT and SDK together in one big undefined configuration.
Back then in the day, ppc+i386/10.4/MacOSX10.4u.sdk seemed
like a reason
39 matches
Mail list logo
