On 2007-03-12 09:29:03 -0400, Daniel J. Luke wrote:
> On Mar 10, 2007, at 9:03 PM, Vincent Lefevre wrote:
> >>... which assumes that the port maintainers are going to know
> >>whenever an API/ABI change occurs in their port (which I doubt is
> >>true for all ports - and I don't know of an automated
On Mar 12, 2007, at 1:47 PM, Ryan Schmidt wrote:
Seems to me that it would be ideal if I could have version A of a
library installed, then install a whole bunch of software that
depends on that library. Then install a new version B of the
library which breaks backward compatibility. Keep bo
On Mar 12, 2007, at 2:08 PM, Jay Sachs wrote:
On Mar 12, 2007, at 4:47 PM, Ryan Schmidt wrote:
On Mar 10, 2007, at 10:11, Daniel J. Luke wrote:
The image mode solution Jordan is proposing would let you upgrade
libiconv without breaking anything, but you really wouldn't be
upgrading libic
On Mar 12, 2007, at 4:47 PM, Ryan Schmidt wrote:
On Mar 10, 2007, at 10:11, Daniel J. Luke wrote:
The image mode solution Jordan is proposing would let you upgrade
libiconv without breaking anything, but you really wouldn't be
upgrading libiconv (as everything you previously built against i
On Mar 10, 2007, at 10:11, Daniel J. Luke wrote:
The image mode solution Jordan is proposing would let you upgrade
libiconv without breaking anything, but you really wouldn't be
upgrading libiconv (as everything you previously built against it
would still be using the old version).
Seems
On Mar 10, 2007, at 9:03 PM, Vincent Lefevre wrote:
... which assumes that the port maintainers are going to know
whenever an API/ABI change occurs in their port (which I doubt is
true for all ports - and I don't know of an automated way we can
improve the macports infrastructure to really help h
On 2007-03-10 11:11:53 -0500, Daniel J. Luke wrote:
> On Mar 10, 2007, at 8:42 AM, Yves de Champlain wrote:
> >Agree on that, who wants to do a clean reinstall of /opt/local because
> >libiconv was upgraded ?
> because someone forced you to upgrade libiconv?
There may be security holes or import
On Mar 10, 2007, at 11:42 AM, Jordan K. Hubbard wrote:
On Mar 10, 2007, at 8:04 AM, Daniel J. Luke wrote:
You'd prefer that burden be foisted on the users, eh? Those who
are perhaps least qualified to diagnose and fix the problem? :-)
Or who are perhaps most qualified to make intelligent cho
On Mar 10, 2007, at 8:04 AM, Daniel J. Luke wrote:
You'd prefer that burden be foisted on the users, eh? Those who
are perhaps least qualified to diagnose and fix the problem? :-)
Or who are perhaps most qualified to make intelligent choices of
what should be installed and upgraded at w
On Mar 10, 2007, at 11:33 AM, Jordan K. Hubbard wrote:
I'm sure you meant that in jest, but actually, that assertion is
completely correct. In order to install all at the same time, we
require the user to take the hit of figuring out how to invoke
the others.
And any other method of choos
On Mar 10, 2007, at 8:03 AM, Daniel J. Luke wrote:
I'm sure you meant that in jest, but actually, that assertion is
completely correct. In order to install all at the same time, we
require the user to take the hit of figuring out how to invoke the
others.
And any other method of choos
On Mar 10, 2007, at 8:42 AM, Yves de Champlain wrote:
The fact that API/ABI compatibility is frequently broken is an
ugly little secret of our business and somebody, somewhere, always
ends up dealing with it. For fan-out reasons alone, that someone
should be as far upstream as possible.
On Mar 9, 2007, at 4:19 PM, Jordan K. Hubbard wrote:
On Mar 9, 2007, at 10:58 AM, Daniel J. Luke wrote:
That's not how image mode works now - and I'm not sure that we
want to impose the burden of verifying abi/api compatibility
between releases on every portfile author (if we were to add hook
On Mar 9, 2007, at 4:17 PM, Jordan K. Hubbard wrote:
This is indeed an issue, though you must admit that this could just
as easily be solved with a little policy. No incompatible API/ABI
changes and just a security fix? Fine, give it a revision number
for auditing purposes (which will not
Le 07-03-09 à 16:19, Jordan K. Hubbard a écrit :
On Mar 9, 2007, at 10:58 AM, Daniel J. Luke wrote:
That's not how image mode works now - and I'm not sure that we
want to impose the burden of verifying abi/api compatibility
between releases on every portfile author (if we were to add hooks
On Mar 9, 2007, at 10:58 AM, Daniel J. Luke wrote:
That's not how image mode works now - and I'm not sure that we want
to impose the burden of verifying abi/api compatibility between
releases on every portfile author (if we were to add hooks to make
things work that way).
You'd prefer tha
On Mar 9, 2007, at 6:53 AM, Daniel J. Luke wrote:
Here's another variant of that:
1 - libfoo.dylib v. 1.0 comes out and it is so good that everyone
starts writing apps that use it.
2 - a serious security flaw is found in libfoo and is fixed in
libfoo v. 1.1 with no api/abi changes
3 - oh n
On Mar 9, 2007, at 12:32 PM, Vincent Lefevre wrote:
On 2007-03-09 09:53:56 -0500, Daniel J. Luke wrote:
Here's another variant of that:
1 - libfoo.dylib v. 1.0 comes out and it is so good that everyone
starts
writing apps that use it.
2 - a serious security flaw is found in libfoo and is fi
On 2007-03-09 09:53:56 -0500, Daniel J. Luke wrote:
> Here's another variant of that:
> 1 - libfoo.dylib v. 1.0 comes out and it is so good that everyone starts
> writing apps that use it.
> 2 - a serious security flaw is found in libfoo and is fixed in libfoo v. 1.1
> with no api/abi changes
>
On Mar 8, 2007, at 11:13 PM, Jordan K. Hubbard wrote:
On Mar 8, 2007, at 4:21 PM, Yves de Champlain wrote:
Of course, I could say that it could also be done with tarballs
instead of hard links and you could say that I really missed the
whole point. But anyway, my original question was "can
On Mar 8, 2007, at 4:21 PM, Yves de Champlain wrote:
Sorry, but I really have a hard time following you here and reading
this leaves me with a deep feeling of deeply missing the whole point.
I understand that the current image implementation is a step in
walk to something else that will so
21 matches
Mail list logo
