Some changes are needed to the install system so that Parrot installs in a fashion that's useable by Rakudo

[wayland]

What the subject says.

I'm discontented with the spec file, both before and after I changed it.

Before, it couldn't be used without tracking down Gerd's patches that don't appear anywhere in the Parrot tree. It seems that one of the other distros is putting their patches in ports/<distroname>; we should do the same, or get them out of the spec file that's used here.

The thing I'm unhappy about after my changes is the section on the documentation that I commented out. I'll have another look at that soon. But I think this patch is an improvement overall, and I wanted to get it in now for review, etc.

[wayland]

Parrot fixes for Rakudo RPM

[jkeenan]

I'm skeptical of the attached patch largely because I'm skeptical that using MANIFEST.configure.generated should be used in the install programs -- and I'm the person who introduced MANIFEST.configure.generated into the Parrot distro in the first place!

A bit of history here: Back in November 2006, particle filed  RT #40817: track generated files during the configure/make process. No one did anything about the ticket for the next 16 months. I had been doing a lot of testing and refactoring of the configuration system, so I took a crack at an intermediate step: tracking those files that were generated while Configure.pl was running. The result was Parrot::Configure::Compiler::append_configure_log() and MANIFEST.configure.generated. But I didn't know how to conduct the 'makefile trickery' that particle suggested would be needed to track files generated while make is running. So that RT was never fully solved, even though recently I closed it and replaced its unsolved parts with TT #677

So MANIFEST.configure.generated wasn't intended to be used by the install programs. Indeed, at the time I created it, I had never looked at the install programs. So any usefulness it may have as part of the install process is purely accidental.

Moreover, as I have discussed in TT #677, it's not simply a question of figuring out what files Configure.pl and make generate. We also need to determine a reliable way of assigning to those files the metadata needed by the install programs. Most of the generated files do not end up getting installed.

I don't claim to have studied the patch thoroughly yet. All I'm saying is that MANIFEST.configure.generated is perhaps not the way to go.

Thank you very much.
kid51

[wayland]

Well, here's the way I see it: - Some of these files need to be installed - (with the patch) The metadata is created as blank by default; no package = not installed - The few files that do need to be installed are now having metadata assigned.

So unless there's something else that needs to read that file too, there's no problem at all. And if something else needs to read it, it can just ignore the irrelevant columns :).

HTH,

[wayland]

Someone on IRC asked me to post this link here:

 http://github.com/samv/rakudo/commit/07dc258cd83b7269ddde5323ffefbdf28870a5b7

He's a Debian guy

[allison]

Could we get an update on this ticket? IIRC, last I checked with Patrick what was needed was changes to the build directory structure so it was a closer match to the install directory structure, and otherwise we're okay.

[wayland]

Hmm. A few things: - I admit that I've kind of dropped out of the Parrot and Rakudo communities for a bit, and don't expect to be back before December. The only thing I'm sure of is that when last I tried to build an RPM of parrot, it didn't work just by getting the release and trying to build it with the spec file. So the spec file certainly needs to be fixed in some way. - You'll notice that all the changes outside the spec file are directed at getting files in runtime/parrot/include to be included in the spec file

After I made this patch, kid51 and I had some discussions about how things should be done. My big plan was to make a library for reading and writing MANIFEST files, and then calling on that from all the places that need that (apparently we have duplicate code doing that, but the duplicate code doesn't match 100%, which is probably a bad thing). IIRC, kid51 wasn't so keen on that, and also said that there was a big discussion coming up on the subject (unless I'm confusing this with something else). But if I've remembered correctly, kid51 and I decided just to sit on this ticket until it had been sorted out whether/how to do a MANIFEST reading/writing library.

What needs to happen on this is: - I need to get back into Parrot/Rakudo - kid51 and I need to revisit the issue together

An alternative would be for someone to try to understand why I created the patch in the first place, since I've forgotten why (having not installed Parrot in about 4 months now). As a step towards that, does anyone know why the files in runtime/parrot/include might be needed? Pmichaud? Someone? Help! :)

[coke]

I'm rejecting this patch - I know that rakudo requires (and uses) an installed version of parrot today to build and run (and also installs itself properly, to boot.)

If you find any issues with the current setup, please don't hesitate to open a new ticket.

Regards.