[Pkg-parrot-devel] Package for parrot-3.6.0 status - work in progress

[Allison Randal]

On 07/27/2011 07:44 PM, Dominique Dumont wrote:
> Hello
>
> I've fixed parrot debian/watch file and pushed this to pkg-parrot git.
>
> I've also updated our git repository with:
> - the modifications Allison did for parrot-3.3.0 (*)
> - parrot-3.6.0
> - some more cleanups

Thanks, I'm nearly finished with the 3.6 packages, will review/integrate
your patches.

> The package builds fine. But there are some issues left:
> - missing dependency on perlapi (because of storable usage). Just adding
> ${perl:Depends} does not work.
>
> I think Ghedo and I can handle the first issue. (probaly ghedo since I'll be
> on vacation real soon)

Great. Where can I get the latest Rakudo packaging to test that the
changes we make in the Parrot packages solve the problem for Rakudo?

> - make sure that parrot-devel and libparrot-dev are not required to install
> rakudo.
>
> We'll need people better knowing parrot to handle the second issue.

Do you have specific failures that are currently preventing rakudo from
installing without depending on parrot-devel and libparrot-dev? Both
will be required to *build* Rakudo, because they include header files.
They shouldn't be required to install, and if they are, then it probably
means a few files need to move from the devel packages into the main
parrot package.

> (*) they were on upstream parrot git. I did a dumb dirdiff to apply Allison's
> modif. If someones know a smarter way to do this with git, I'm all ears...

I'm at DebConf this week, and have been talking to people about Debian
packaging workflows for git. There are a variety of different tools, but
our options basically boil down to:

* make our git repository a branch of the full set of parrot changes,
with the tarballs tagged over existing release tags, and our debian/
directory added on top

* make our git repository a log of debian releases (and relevant parrot
tarballs), with our debian/ directory included

* make our git repository a record of our debian/ directory only

I'm inclined to go with the second, as that gives us the best record of
history of Debian Parrot packages, without requiring everyone who
contributes to the Debian packaging to cope with the full complexity of
Parrot development.

We have more details to decide on workflows, but deciding on the base
contents of the repository is the first step.

Allison