[MacPorts] #26357: new Portfile for xchataqua
MacPorts
noreply at macports.org
Sun Sep 5 07:19:23 PDT 2010
#26357: new Portfile for xchataqua
------------------------------+---------------------------------------------
Reporter: ToePeu@… | Owner: ryandesign@…
Type: submission | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 1.9.1
Keywords: | Port: xchataqua
------------------------------+---------------------------------------------
Comment(by ryandesign@…):
Replying to [comment:4 ToePeu@…]:
> There was a problem with leopard-perl installation
>
> perl-plugin problem:
> while installing, there is a Terminal.app popup requiring sudo
password.
> after password and trying again, it will success.
> if you know something better way, please help me.
The first time I tried to install from this Portfile, it popped up a
second Terminal window asking me for my password to run "sudo tar xvf
"/opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_xchataqua/work/xchataqua-0.17-rc2-20100905/contrib/systemlib
/Perl-Leopard.tar" -P", but before I could type my password, the original
Terminal window showed the "port install" command already failed as I
reported before, and I cancelled the tar command. The second time I tried,
the second Terminal window appeared and proceeded to extract the tar file
without needing my password (I guess it had been less than 5 minutes since
I had last given sudo my password) but the "port install" window still
failed. On the third try xchataqua installed successfully. But this
solution is not going to be acceptable for several reasons. It's not nice
to pop up a second Terminal window, nor to make the user attempt the
installation multiple times. And it's totally unacceptable for a port to
install things into /System; ports should be self-contained within
${prefix} or other approved directories like ${applications_dir} and must
not modify directories that are "owned" by Apple. These files were also
extracted directly into /System, not into ${destroot}, so they're not
registered to the port, which means they won't go away with a "port
uninstall"; it's not ok to litter the user's system with files like that.
In MacPorts we like to [wiki:FAQ#ownlibs use our own libraries], so you
should be using MacPorts perl instead of the system's perl; this change
alone would resolve many of the above issues.
> sed errors:
> it is not harmful most of users. it just makes pa localization
disabled.
There appears to be some confusion in the localization files about what
the correct syntax is for the SET command. Is it:
* SET <variable> [<value>]
* SET [-quiet] <variable> [<value>]
* SET [-e] [-or] [-quiet] <variable> [<value>]
* SET [-e] [-off|-on] [-quiet] <variable> [<value>]
When inserted into a sed statement, as you do, this last variant becomes
invalid sed syntax (and this last variant only appears in the pa
localization). "![" and "]" delimit character classes in a sed statement,
so for example "[-e]" means "any single character '-' or 'e'".
"[-off|-on]" is not a valid character class. The "-", when it does not
appear at the very beginning or end of the character class, is used to
indicate a range of characters. In this case, you've asked for the range
of characters from "|" to "o" which doesn't work because the ASCII code
for "|" (124) is higher than the ASCII code for "o" (111). Clearly in this
case you don't want "![" and "]" to be delimiting character classes; you
just want the literal square bracket characters to be matched, so they
need to be escaped wih backslashes to turn off their special meaning. I
believe the attached patch fixes this problem. You should then fix the
strings to all use the same syntax for the SET command. Other strings may
be out of date as well; I did not evaluate them.
--
Ticket URL: <http://trac.macports.org/ticket/26357#comment:6>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list