Make 1.6.0 the default version for new tickets
When filing a new ticket, the default MacPorts version is still 1.5.2. Since 1.6.0 has been released, this should be changed to 1.6.0.
But there's no working 1.6 binary for OS X 10.3. Wouldn't it be nice to postpone that change after the fix? (I won't be long, right?) On Dec 23, 2007 11:41 AM, Ryan Schmidt <ryandesign@macports.org> wrote:
When filing a new ticket, the default MacPorts version is still 1.5.2. Since 1.6.0 has been released, this should be changed to 1.6.0.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
I would guess that most of our users are using 10.4 or 10.5, and I think the defaults in the issue tracker should reflect what most users want. On Dec 22, 2007, at 21:25, js wrote:
But there's no working 1.6 binary for OS X 10.3. Wouldn't it be nice to postpone that change after the fix? (I won't be long, right?)
On Dec 23, 2007 11:41 AM, Ryan Schmidt wrote:
When filing a new ticket, the default MacPorts version is still 1.5.2. Since 1.6.0 has been released, this should be changed to 1.6.0.
You're right. It's sad to admit Panther isn't in main stream anymore, though. On Dec 23, 2007 2:11 PM, Ryan Schmidt <ryandesign@macports.org> wrote:
I would guess that most of our users are using 10.4 or 10.5, and I think the defaults in the issue tracker should reflect what most users want.
On Dec 22, 2007, at 21:25, js wrote:
But there's no working 1.6 binary for OS X 10.3. Wouldn't it be nice to postpone that change after the fix? (I won't be long, right?)
On Dec 23, 2007 11:41 AM, Ryan Schmidt wrote:
When filing a new ticket, the default MacPorts version is still 1.5.2. Since 1.6.0 has been released, this should be changed to 1.6.0.
On Sun, December 23, 2007 2:25 pm, js wrote:
But there's no working 1.6 binary for OS X 10.3. Wouldn't it be nice to postpone that change after the fix? (I won't be long, right?)
I was hoping that it'd be out by now (I've been working with Juan to build the dmg for 10.3), but I ran into a 10.3-only runtime bug when building from the 1.6 source and Juan hasn't got back to me with a fix for it yet. I hadn't filed a ticket for it as I'd been in direct contact with Juan about it, but if anybody has a 10.3 system and would like to see if they can reproduce the bug (and hopefully fix it), I'd be happy to file a ticket to describe how to do so (unfortunately, we found that the 1.6 source tarball won't even build directly on Mac OS X; it needs to be patched first). Kind regards, Maun Suang
On Dec 24, 2007, at 1:28 AM, Boey Maun Suang wrote:
On Sun, December 23, 2007 2:25 pm, js wrote:
But there's no working 1.6 binary for OS X 10.3. Wouldn't it be nice to postpone that change after the fix? (I won't be long, right?)
I was hoping that it'd be out by now (I've been working with Juan to build the dmg for 10.3), but I ran into a 10.3-only runtime bug when building from the 1.6 source and Juan hasn't got back to me with a fix for it yet. I hadn't filed a ticket for it as I'd been in direct contact with Juan about it, but if anybody has a 10.3 system and would like to see if they can reproduce the bug (and hopefully fix it), I'd be happy to file a ticket to describe how to do so (unfortunately, we found that the 1.6 source tarball won't even build directly on Mac OS X; it needs to be patched first).
Kind regards,
Maun Suang
I'm sorry for taking so long to get back to you on this issue, Maun Suang, but I've been both away for the last three days and unable to test, as I don't have access to any Panther box I can test on. Nevertheless, I'll try looking into the report you sent me to see if I can come up with at least a theory... and hopefully work our way up from there. If no one hits the bull's eye on this bug then I guess we're going to have to discuss what to do about the Panther dmg and maybe even Panther support as a whole. But lets not get too ahead of ourselves just yet, I'll look again at your report before proposing any alternatives. About 1.6 and Trac, I just made it default for new tickets. Regards,... -jmpp PS: Users on Panther that selfupdate will be pushed up to 1.6, so I'm hoping we'll be able to gather some more information if the error is a widespread one.
On Dec 24, 2007, at 01:03, Juan Manuel Palacios wrote:
I'm sorry for taking so long to get back to you on this issue, Maun Suang, but I've been both away for the last three days and unable to test, as I don't have access to any Panther box I can test on. Nevertheless, I'll try looking into the report you sent me to see if I can come up with at least a theory... and hopefully work our way up from there. If no one hits the bull's eye on this bug then I guess we're going to have to discuss what to do about the Panther dmg and maybe even Panther support as a whole. But lets not get too ahead of ourselves just yet, I'll look again at your report before proposing any alternatives.
Why is it again that we need separate dmgs for separate OS releases at all? Why don't we just have a single universal dmg, with the PowerPC part built with the 10.3.9 SDK and the Intel part built with the 10.4u SDK, and everyone's happy? Isn't that the whole point of universal binaries and those SDKs? Frankly, that's how I'd like ports built too, when the +universal binary is selected. But that can be a separate topic for another day.
Why is it again that we need separate dmgs for separate OS releases at all? Why don't we just have a single universal dmg, with the PowerPC part built with the 10.3.9 SDK and the Intel part built with the 10.4u SDK, and everyone's happy? Isn't that the whole point of universal binaries and those SDKs?
What you pointed out is not a new issue. There're separate dmgs for 1.5.0. http://svn.macports.org/repository/macports/downloads/MacPorts-1.5.0/
Ryan Schmidt wrote:
Why is it again that we need separate dmgs for separate OS releases at all? Why don't we just have a single universal dmg, with the PowerPC part built with the 10.3.9 SDK and the Intel part built with the 10.4u SDK, and everyone's happy? Isn't that the whole point of universal binaries and those SDKs?
Frankly, that's how I'd like ports built too, when the +universal binary is selected. But that can be a separate topic for another day.
As +universal is not the default (a very good thing IMHO), why should we distribute the MacPorts base system as universal? I don't like these universal stuff at all, for most people it is occupying disk space for no actual use. Most people will use one MacPorts installation on one system - which is obviously one architecture. Rainer
On Dec 28, 2007, at 10:11, Rainer Müller wrote:
Ryan Schmidt wrote:
Why is it again that we need separate dmgs for separate OS releases at all? Why don't we just have a single universal dmg, with the PowerPC part built with the 10.3.9 SDK and the Intel part built with the 10.4u SDK, and everyone's happy? Isn't that the whole point of universal binaries and those SDKs?
Frankly, that's how I'd like ports built too, when the +universal binary is selected. But that can be a separate topic for another day.
As +universal is not the default (a very good thing IMHO), why should we distribute the MacPorts base system as universal? I don't like these universal stuff at all, for most people it is occupying disk space for no actual use. Most people will use one MacPorts installation on one system - which is obviously one architecture.
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? 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. 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. As for +universal variants in ports, most users won't need to select this variant themselves, but once we get to distributing compiled binaries of ports, which is a long-term goal, I think we would want to distribute universal binaries so that we only have to manage a single collection of binaries, and not multiple collections, one for each architecture. Anyway we don't really need to debate anymore *whether* we should have universal support. We already do, and I see no reason why it should be removed; rather, I see reasons why it should be kept and improved.
participants (5)
-
Boey Maun Suang
-
js
-
Juan Manuel Palacios
-
Rainer Müller
-
Ryan Schmidt