Reini Urban wrote:
Problem:
Most packages will not accept packages with /usr/bin/scheme,
/usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh
were these are the parrot implementations.
Of course we don't want to hijack existing language executables in the
distribution packages. But, it should be an easy compilation option in
case, for example, someone is setting up a tiny embedded linux and wants
to run Parrot in place of a whole collection of languages.
It's important to keep in mind that for the most part, at least on
unix-related operating systems, executables for a particular language
will simply be an 'ln -s' to /usr/bin/parrot (taking advantage of the $0
executable name information to set up certain configuration for the
runtime environment).
So most packages use the "parrot-" prefix for all language installables,
the pbc is without this prefix. With fedora and cygwin, the rest does
not install language installables yet.
And really, it's not only polite packaging practice, we *want* the
"parrot-" prefix, it's good marketing for the virtual machine.
The pbc files are not executables, and should be installed in a library
directory, not in /usr/bin/.
Current exceptions for the "parrot-" prefix:
perl6
Actually, that probably won't be an exception to the "parrot-" prefix on
the package name, since there are multiple implementations of Perl 6.
Future possible exceptions:
cardinal, chitchat, cola, eclectus, pheme, pynie, punie, squaak
(wise choice in the names)
For consistency I would suggest to introduce no such exceptions,
besides perl6. But this is just a personal favor.
Again, it should be a configuration option to install aliases for
executables with the language "nicknames". Not a requirement for the
packaged versions, but the $0 handling will be built in to Parrot, so
the user could also easily create their own 'ln -s' aliases.
Allison
