New "file delete" implementation breaks ncurses
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}/lib/terminfo ${destroot}${prefix}/share ncurses installs correctly (lib/terminfo is a symbolic link to ../ share/terminfo). I have already submitted a bug report through Trac (http://trac.macosforge.org/projects/macports/ticket/11878) but it doesn't have been reviewed for too long.
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 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}/lib/terminfo ${destroot}${prefix}/share
ncurses installs correctly (lib/terminfo is a symbolic link to ../ share/terminfo).
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
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 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 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}/lib/terminfo ${destroot}${prefix}/share
ncurses installs correctly (lib/terminfo is a symbolic link to ../ share/terminfo).
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
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 safely broken for periods of time. :-(
On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
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 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}/lib/terminfo ${destroot}${prefix}/share
ncurses installs correctly (lib/terminfo is a symbolic link to ../ share/terminfo).
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 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. :-(
On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
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 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}/lib/terminfo ${destroot}${prefix}/share
ncurses installs correctly (lib/terminfo is a symbolic link to ../share/terminfo).
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...
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:
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 safely broken for periods of time. :-(
On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
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 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}/lib/terminfo ${destroot}${prefix}/ share
ncurses installs correctly (lib/terminfo is a symbolic link to ../share/terminfo).
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
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 simply be deleted without trying to traverse them.
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 revision bump, by the way? If I already had ncurses successfully installed using a version of MacPorts where delete works properly (<=1.4.3?), then there is no need for me to install it again. And if I had a version of MacPorts with the new "file delete" implementation (>1.4.3?), then wouldn't I have been completely unable to install ncurses in the first place?
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/macports/changeset/24928
Why did that necessitate a revision bump, by the way? If I already had ncurses successfully installed using a version of MacPorts where delete works properly (<=1.4.3?), then there is no need for me to install it again. And if I had a version of MacPorts with the new "file delete" implementation (>1.4.3?), then wouldn't I have been completely unable to install ncurses in the first place?
Hi Ryan, I wasn't sure what state this caused things to end up in. I've removed the revision bump. James
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 days when I get home from vacation. On May 8, 2007, at 12:24 PM, 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/macports/changeset/24928
Why did that necessitate a revision bump, by the way? If I already had ncurses successfully installed using a version of MacPorts where delete works properly (<=1.4.3?), then there is no need for me to install it again. And if I had a version of MacPorts with the new "file delete" implementation (>1.4.3?), then wouldn't I have been completely unable to install ncurses in the first place?
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
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 workaround seems to work already as it is: currently, "delete" does remove both the symlink and the target directory, otherwise it would conflict with ncursesw and the activation wouldn't succeed.
participants (6)
-
Guido Soranzio
-
James Berry
-
Jordan K. Hubbard
-
Kevin Ballard
-
Paul Guyot
-
Ryan Schmidt