After the changes to the "file delete" implementation, the
installation of
ncurses fails because it tries to follow the target of a symbolic link.
By reversing the order of the arguments from
delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo
into
delete ${destroot}${prefix
Oh hrm, it didn't occur to me that this would happen, but I know
exactly why.
However, I'm on vacation. Can this wait a week? It's a problem that
only affects trunk.
On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:
After the changes to the "file delete" implementation, the
installation
Why can't we get the work-around committed for now? A lot of things
depend on ncurses, and it's a fallacy to assume that a lot of people
don't track trunk and it can be safely broken for periods of time. :-(
- Jordan
On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
Oh hrm, it didn't occur
MacPorts 1.4.40 was released, so I hope the fix made it into that...
On May 8, 2007, at 02:46, Jordan K. Hubbard wrote:
Why can't we get the work-around committed for now? A lot of
things depend on ncurses, and it's a fallacy to assume that a lot
of people don't track trunk and it can be sa
AFAIK, the fix hasn't even been committed to trunk yet...
- Jordan
On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
MacPorts 1.4.40 was released, so I hope the fix made it into that...
On May 8, 2007, at 02:46, Jordan K. Hubbard wrote:
Why can't we get the work-around committed for now? A lo
So maybe it's time for 1.4.41 :D
Paul
On May 8, 2007, at 5:04 PM, Jordan K. Hubbard wrote:
AFAIK, the fix hasn't even been committed to trunk yet...
- Jordan
On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
MacPorts 1.4.40 was released, so I hope the fix made it into that...
--
http://pau
If I understand Guido's suggestion, the workaround is to the
Portfile, not to trunk, right? Who wants to fix it?
James
On May 8, 2007, at 1:04 AM, Jordan K. Hubbard wrote:
AFAIK, the fix hasn't even been committed to trunk yet...
- Jordan
On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
M
On May 8, 2007, at 2:47 PM, James Berry wrote:
If I understand Guido's suggestion, the workaround is to the
Portfile, not to trunk, right?
The problem is that "delete" now tries to follow the orphan symbolic
links.
IMHO, the "can't find" message is confusing: the orphan links should
simp
On May 8, 2007, at 07:47, James Berry wrote:
If I understand Guido's suggestion, the workaround is to the
Portfile, not to trunk, right? Who wants to fix it?
Looks like you committed a fix already:
http://trac.macosforge.org/projects/macports/changeset/24928
Why did that necessitate a revi
On May 8, 2007, at 9:24 AM, Ryan Schmidt wrote:
On May 8, 2007, at 07:47, James Berry wrote:
If I understand Guido's suggestion, the workaround is to the
Portfile, not to trunk, right? Who wants to fix it?
Looks like you committed a fix already:
http://trac.macosforge.org/projects/macpor
That's not actually a fix. You should revert it, then change it to
two different commands a - delete for the real folder, and a 'file
delete' for the symlink. The reason this isn't a fix is it will not
delete the symlink this way.
I'll commit a fix to trunk for the 'delete' command in a few
On May 8, 2007, at 9:16 PM, Kevin Ballard wrote:
That's not actually a fix. You should revert it, then change it to
two different commands a - delete for the real folder, and a 'file
delete' for the symlink. The reason this isn't a fix is it will not
delete the symlink this way.
My worka
12 matches
Mail list logo
