Ryan Schmidt wrote:
Rainer, would you prefer for us to distribute 5 different disk images of MacPorts then -- Panther PowerPC, Tiger PowerPC, Tiger Intel, Leopard PowerPC, Leopard Intel?
A disk image with four architectures will be around four times bigger than it needs to be... Why should anybody want to download a large file if 3/4 are useless data and just occupy disk space?
Apple wants developers to make universal binaries so that users don't need to care what kind of processor they have. Other Mac developers are making universal binaries. We should too. And we already do. We just have separate images for Panther, Tiger and Leopard right now. And I'd like to unify that as well so that we end up with a single downloadable for our software, like most other Mac developers already have.
So why does Apple not just provide a interface to strip uneeded architectures right on installing? Instead, they copy useless data. I don't understand this... At least one can do it himself and remove them with ditto.
We already had several cases where users downloaded the Leopard MacPorts disk image, installed it on Tiger, and of course it didn't work. So distributing a single disk image which works everywhere is simpler for users.
[Those stupid users should learn to read...] But if you download an universal disk image; after the first selfupdate, which you normally do after install to get a newer minor version, you will end up with a single architecture - the one of your system. Why should disk images distribute a different version than selfupdate? I don't want to debate over support universal building for ports, somebody might need it. And I don't want to say that universal in general is bad. Rainer
Even though I do believe that Universal building is a bit of a waste of space more often than not for most, I do buy into the simplicity such builds report for users that only have to go looking for a single download link. Maybe Markus could advise us on how we could achieve this through the MacPorts Portfile (sudo port dmg MacPorts)? In any case, for the time being while we have separate dmg's for different felines, I already cleared up a bit the instructions on www.macports.org/install.php so that it's clear which one is needed for each platform. Maun Suang, since you reported to me that you already got the Panther dmg built, and that the errors you're experiencing (ui_prefix) manifest themselves regardless of whether you install from the dmg or from source, what would you say about uploading that dmg regardless of the bug? Kevin introduced some code to hunt down those errors, but that wont see the light of day until 1.6.1, which is orthogonal to the dmg. Regards,.... -jmpp On Dec 28, 2007, at 1:34 PM, Rainer Müller wrote:
Ryan Schmidt wrote:
Rainer, would you prefer for us to distribute 5 different disk images of MacPorts then -- Panther PowerPC, Tiger PowerPC, Tiger Intel, Leopard PowerPC, Leopard Intel?
A disk image with four architectures will be around four times bigger than it needs to be... Why should anybody want to download a large file if 3/4 are useless data and just occupy disk space?
Apple wants developers to make universal binaries so that users don't need to care what kind of processor they have. Other Mac developers are making universal binaries. We should too. And we already do. We just have separate images for Panther, Tiger and Leopard right now. And I'd like to unify that as well so that we end up with a single downloadable for our software, like most other Mac developers already have.
So why does Apple not just provide a interface to strip uneeded architectures right on installing? Instead, they copy useless data. I don't understand this... At least one can do it himself and remove them with ditto.
We already had several cases where users downloaded the Leopard MacPorts disk image, installed it on Tiger, and of course it didn't work. So distributing a single disk image which works everywhere is simpler for users.
[Those stupid users should learn to read...]
But if you download an universal disk image; after the first selfupdate, which you normally do after install to get a newer minor version, you will end up with a single architecture - the one of your system. Why should disk images distribute a different version than selfupdate?
I don't want to debate over support universal building for ports, somebody might need it. And I don't want to say that universal in general is bad.
Rainer
On Jan 8, 2008, at 15:14, Juan Manuel Palacios wrote:
Even though I do believe that Universal building is a bit of a waste of space more often than not for most, I do buy into the simplicity such builds report for users that only have to go looking for a single download link. Maybe Markus could advise us on how we could achieve this through the MacPorts Portfile (sudo port dmg MacPorts)?
Why don't we instead change the base Makefile so that it builds universal (for 10.3.9 on PPC, for 10.4u on i386). That way, you get a universal build no matter how you do it, whether through the MacPorts Portfile, manually, or via selfupdate. This would also address Rainer's concerns from earlier, which may be a valid point (that selfupdate would make it non-universal again) (though I haven't tested whether this is really the case) (though I could see that it might be):
On Dec 28, 2007, at 1:34 PM, Rainer Müller wrote:
But if you download an universal disk image; after the first selfupdate, which you normally do after install to get a newer minor version, you will end up with a single architecture - the one of your system. Why should disk images distribute a different version than selfupdate?
On Jan 8, 2008, at 4:44 PM, Juan Manuel Palacios wrote:
Maun Suang, since you reported to me that you already got the Panther dmg built, and that the errors you're experiencing (ui_prefix) manifest themselves regardless of whether you install from the dmg or from source, what would you say about uploading that dmg regardless of the bug? Kevin introduced some code to hunt down those errors, but that wont see the light of day until 1.6.1, which is orthogonal to the dmg.
I should definitely keep a closer eye on the users list! ;-) I just realized there that the Panther runtime problems have been corrected (kevin's try-catch blocks, so much for my 1.6.1 related comments;-), so there shouldn't be any problem in uploading the 1.6.0 dmg for Panther. Once a user installs off that, the postfligth script will selfupdate to 1.6.1 when we release it, so Panther users will hopefully not see the runtime errors. -jmpp
On Wed, January 9, 2008 8:14 am, Juan Manuel Palacios wrote:
Maun Suang, since you reported to me that you already got the Panther dmg built, and that the errors you're experiencing (ui_prefix) manifest themselves regardless of whether you install from the dmg or from source, what would you say about uploading that dmg regardless of the bug?
Actually, I never built the Panther dmg precisely because the ui_prefix/ui_channels problem prevented me from accessing sysutils/MacPorts! (I not sure how I gave the impression that I had, but apologies for however it happened). Anyway, I've now created the Panther dmg by applying the patches from r32105 [1], r32212 [2], r32514 [3] and r32525 [4] after sysutils/MacPorts' patch phase; these patches were cherry-picked to ensure that the Panther dmg is as close as possible to the Tiger and Leopard ones. The resultant Panther dmg passes the tests in the "Create Release Disk Image(s)" section of base/portmgr/ReleaseProcess, with the caveat that daemondo isn't built on Panther (see the configure script test for CFNotificationCenterGetDarwinNotifyCenter(), which is only in 10.4 and later [5]) and thus doesn't need testing; I updated ReleaseProcess to reflect this in r32631. The dmg and checksums updates were uploaded in r32630, but I'll leave it to you as to when to restore the links to it from www.macports.org. By the way, Juan, /trunk/base/portmgr/dmg/postflight in the repository seems well out of sync with /branches/release_1_6/base/portmgr/dmg/postflight. Is that supposed to be the case? Kind regards, Maun Suang [1] http://trac.macosforge.org/projects/macports/changeset/32105 [2] http://trac.macosforge.org/projects/macports/changeset/32212 [3] http://trac.macosforge.org/projects/macports/changeset/32514 [4] http://trac.macosforge.org/projects/macports/changeset/32525 [5] http://developer.apple.com/documentation/CoreFoundation/Reference/CFNotifica... -- Boey Maun Suang Email: boeyms@macports.org
On Jan 10, 2008, at 1:29 AM, Boey Maun Suang wrote:
On Wed, January 9, 2008 8:14 am, Juan Manuel Palacios wrote:
Maun Suang, since you reported to me that you already got the Panther dmg built, and that the errors you're experiencing (ui_prefix) manifest themselves regardless of whether you install from the dmg or from source, what would you say about uploading that dmg regardless of the bug?
Actually, I never built the Panther dmg precisely because the ui_prefix/ui_channels problem prevented me from accessing sysutils/MacPorts! (I not sure how I gave the impression that I had, but apologies for however it happened).
So, you installed MacPorts 1.6.0 from source on Panther and then with that installation attempted to build the dmg? Gotta love bugs while bootstrapping! ;-) I thought you had 1.5.2 or earlier installed and were working off that. But in any case,....
Anyway, I've now created the Panther dmg by applying the patches from r32105 [1], r32212 [2], r32514 [3] and r32525 [4] after sysutils/ MacPorts' patch phase; these patches were cherry-picked to ensure that the Panther dmg is as close as possible to the Tiger and Leopard ones.
All these patches are minor and will shortly end up in the release_1_6 branch, so I don't think there's any problem in having them in this not-so-stock 1.6.0 Panther dmg. Thanks for the hard work!
The resultant Panther dmg passes the tests in the "Create Release Disk Image(s)" section of base/portmgr/ReleaseProcess, with the caveat that daemondo isn't built on Panther (see the configure script test for CFNotificationCenterGetDarwinNotifyCenter(), which is only in 10.4 and later [5]) and thus doesn't need testing; I updated ReleaseProcess to reflect this in r32631.
Sure thing, thanks for adding the note to the ReleaseProcess file.
The dmg and checksums updates were uploaded in r32630, but I'll leave it to you as to when to restore the links to it from www.macports.org.
Done!
By the way, Juan, /trunk/base/portmgr/dmg/postflight in the repository seems well out of sync with /branches/release_1_6/base/portmgr/dmg/postflight. Is that supposed to be the case?
Yes. See http://lists.macosforge.org/pipermail/macports-users/2008-January/008206.htm... for the explanation why.
Kind regards,
Maun Suang
Regards,.... -jmpp
On Jan 8, 2008, at 5:08 PM, Ryan Schmidt wrote:
On Jan 8, 2008, at 15:14, Juan Manuel Palacios wrote:
Even though I do believe that Universal building is a bit of a waste of space more often than not for most, I do buy into the simplicity such builds report for users that only have to go looking for a single download link. Maybe Markus could advise us on how we could achieve this through the MacPorts Portfile (sudo port dmg MacPorts)?
Why don't we instead change the base Makefile so that it builds universal (for 10.3.9 on PPC, for 10.4u on i386). That way, you get a universal build no matter how you do it, whether through the MacPorts Portfile, manually, or via selfupdate. This would also address Rainer's concerns from earlier, which may be a valid point (that selfupdate would make it non-universal again)
That's a very good suggestion, Ryan, thanks! Nevertheless, as I'm a bit out of time for the moment, I can't help employing Open Source's most enjoyable principle: care to propose a patch? ;-) Regards,... -jmpp
participants (4)
-
Boey Maun Suang
-
Juan Manuel Palacios
-
Rainer Müller
-
Ryan Schmidt