Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

rpm package

2 views
Skip to first unread message

Steven Pritchard

unread,
Mar 17, 2007, 8:34:15 PM3/17/07
to perl6-i...@perl.org
I spent some more time getting a package built for Fedora. It
probably goes without saying, but this is still a bit difficult. If
anyone is interested, here's my current package:

http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec
http://ftp.kspei.com/pub/steve/rpms/parrot-0.4.9-1.src.rpm

Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: st...@kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320

Allison Randal

unread,
Mar 21, 2007, 6:13:55 PM3/21/07
to Steven Pritchard, perl6-i...@perl.org
Steven Pritchard wrote:
> I spent some more time getting a package built for Fedora. It
> probably goes without saying, but this is still a bit difficult. If
> anyone is interested, here's my current package:

Thanks, Steve. Have you kept a list of the things that are difficult
about the process? Making it easy to package up Parrot for .rpm, .deb,
etc, is definitely one of our goals.

Allison

Chromatic

unread,
Mar 21, 2007, 8:21:30 PM3/21/07
to perl6-i...@perl.org, Allison Randal, Steven Pritchard

> Steven Pritchard wrote:

My theory: the "all Parrot developers work from within the tree, so
installation paths are either not present or wrong" problem is a big problem.

-- c

Allison Randal

unread,
Mar 21, 2007, 9:39:51 PM3/21/07
to chromatic, perl6-i...@perl.org
chromatic wrote:
>
> My theory: the "all Parrot developers work from within the tree, so
> installation paths are either not present or wrong" problem is a big problem.

Agreed. And we don't work from the installation paths because the
installation paths are broken. Can we break out of this cycle with some
automated tests for the installed Parrot?

Allison

Steven Pritchard

unread,
Mar 22, 2007, 7:14:40 PM3/22/07
to Allison Randal, chromatic, perl6-i...@perl.org
On Wed, Mar 21, 2007 at 06:39:51PM -0700, Allison Randal wrote:
> Agreed. And we don't work from the installation paths because the
> installation paths are broken. Can we break out of this cycle with some
> automated tests for the installed Parrot?

That would be pretty slick. :-)

Steven Pritchard

unread,
Mar 22, 2007, 7:13:49 PM3/22/07
to Allison Randal, perl6-i...@perl.org

I didn't keep a list, but I do have the spec. Quickly glancing at it,
I see three things that I would classify as problems:

1) "lib" is hard-coded in a few places. (On x86_64 Fedora and other
RH derivatives, the system library path is /lib64 and /usr/lib64.)
I hack around that in %prep with this:

%{__perl} -pi -e 's,"lib/,"%{_lib}/, if (/CONST_STRING\(interp,/)' \
src/library.c
%{__perl} -pi -e "s,'/usr/lib','%{_libdir}',;s,runtime/lib/,runtime/%{_lib}/," \
tools/dev/install_files.pl \
tools/dev/mk_manifests.pl

Ideally, the install scripts should allow for installing
non-architecture-specific bits in /usr/share and the
architecture-specific binary bits in /usr/lib64.

2) The last time I checked, to get everything to work right I had to
set LD_LIBRARY_PATH to $topdir/blib/lib.

3) The languages/ stuff isn't installed automatically. I'm not even
sure where it should go.

The rest is all minor cleanup and sub-optimal (for my purposes)
defaults. If you look through the spec, it should all be pretty
obvious...

Mike Mattie

unread,
Mar 23, 2007, 8:51:05 AM3/23/07
to perl6-i...@perl.org

I have already suggested in a previous mail "the value of a install target"
the goal of making the working copy and the install target exercise the
loader in the same way.

The reason I chose the language: "exercise the loader" was to dodge this testing
bullet.

Expanding the test-suite to cover the install target is alot of work, and
an unpleasant administrative burden to remind and cajole the developers into
passing the install tests; which they may not even care about.

If it was built in a traditional way the test-suite would also have to
be extended as the project grew with coverage testing, it's a vicious cycle :)

The answer is to make a guarantee of a flat search space for modules.
Authors can insert into that search space foo.pir or myproject/foo.pir.

This flat search space needs to be assembled in the *working-copy* and
in the install tree.

In fact parrot does this already !

here is a snip from src/library.c:90

<snip>
entry = CONST_STRING(interp, "runtime/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>

and from src/library.c:94

<snip>
entry = CONST_STRING(interp, "lib/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>

This hack is built-in for the runtime core. What is really missing is a
comprehensive design that de-couples policy (where things go) from
hand-editing source files.

Once this table in library.c is generated from a policy spec, that policy
can either describe what the install should be, _and_ what the working-copy is.

Ideally an author should be able to create

project/main.pir
project/foo/bar/install.spec
project/foo/bar/bar.pbc
project/foo/bar/mystuff/util.pbc

and in main.pir do this:

.load_bytecode "bar"
.load_bytecode "mystuff/util"

and this would work because install.spec ( name doesn't matter at this point )
has specified that the files and directories below are relative to the flat
search space.

Note that ideally the author would simply setup such a install.spec file at the
beginning, update parrot with the new policy, and at that point ignore the
file except occasionally adding/removing pieces to install. Once the path has
been added to the search path list it is a true member of the unified name-space.

With this scheme the testing is focused on a single point: the loader. The loader
is significantly enhanced with powerful features integrated into a comprehensive
design. Once that basket is well-built things either load or they don't , irrespective
of whether it is installed or not.

In short this will make things work, because things will break for developers as they
would for users, a isomorphic mapping that sidesteps non-linear growth in the test-suite.

The key is the design, which unfortunately I don't have the time to put out in this mail.
I have it in my head, and I will sketch it out in a diagram.

If someone could point me at a suitable related wiki, or other hosting location where I could
upload a .png diagram, and some text describing the design I have developed I should be able
to assemble this sometime within the next week or two.

Cheers,
Mike Mattie (coder...@gmail.com)

signature.asc

Paul Cochrane

unread,
Mar 23, 2007, 9:21:47 AM3/23/07
to Mike Mattie, perl6-i...@perl.org
Mike,

> If someone could point me at a suitable related wiki, or other hosting location where I could
> upload a .png diagram, and some text describing the design I have developed I should be able
> to assemble this sometime within the next week or two.

The Parrot wiki is probably the place to put it:

http://rakudo.org/parrot/index.cgi?parrot

Paul

Chromatic

unread,
Mar 23, 2007, 11:15:12 AM3/23/07
to perl6-i...@perl.org, Mike Mattie
On Friday 23 March 2007 05:51, Mike Mattie wrote:

> This hack is built-in for the runtime core. What is really missing is a
> comprehensive design that de-couples policy (where things go) from
> hand-editing source files.

Last October or November, I posted a PIR snippet that demonstrated how to
modify the interpreter's search paths at runtime. I don't have time to find
the code now, but it's doable from PIR.

That could become a library similar to lib.pm in Perl 5.

-- c

Joshua Isom

unread,
Mar 23, 2007, 1:35:24 PM3/23/07
to Mike Mattie, perl6-i...@perl.org
On Mar 23, 2007, at 7:51 AM, Mike Mattie wrote:

> On Wed, 21 Mar 2007 18:39:51 -0700
> Allison Randal <all...@perl.org> wrote:
>
>> chromatic wrote:
>>
>> Agreed. And we don't work from the installation paths because the
>> installation paths are broken. Can we break out of this cycle with
>> some automated tests for the installed Parrot?
>>
>> Allison
>
> I have already suggested in a previous mail "the value of a install
> target"
> the goal of making the working copy and the install target exercise the
> loader in the same way.
>
> The reason I chose the language: "exercise the loader" was to dodge
> this testing
> bullet.

Actually, I don't believe that it would be that difficult. All that
should need to happen is change which parrot is ran. A
"test_installed" target that isn't dependent on building
parrot(confusing, but think of how the Makefile works) that runs the
installed parrot, and using the local perl modules should suffice. I
imagine it'd be one of the easier parts of a complete installed parrot.

0 new messages