Problems with read-only MANIFEST
Andy Dougherty
Unfortunately, that now fails due to the MANIFEST check in
config/init/manifest.pl:
Parrot Version 0.0.10 Configure 2.0
[ . . .]
Generating and checking MANIFEST...
create MANIFEST: Permission denied at config/init/manifest.pl line 15.
I'd suggest a fix, but I'm unclear as to the intention. Specifically,
if parrot's going to generate a MANIFEST anyway, why include one at
all? Thus perhaps the solution is to *remove* MANIFEST from
MANIFEST.detailed (and hence from the distribution).
On the other hand, I do find it handy to have a MANIFEST file in parrot
and wonder what's truly gained by having a separate MANIFEST.detailed
file. This is reinforced by the fact that Perl's had a MANIFEST file
for ages, already includes some tools to deal with it, and porters
probably also have their own home-grown tools to do various things with
it. For example, I routinely build fresh source trees with commands like
awk '{print $1}' MANIFEST | cpio -pdmv ../parrot-new
(which also doesn't work right anymore because of the auto-generated
comment at the top of the new MANIFEST file).
Perhaps we should run
awk '{printf "%s\t%s\n", $2, $1}' MANIFEST.detailed > MANIFEST ,
put the extra stuff on the last 5 lines of MANIFEST.detailed into
something like MANIFEST.locations or something, and delete
MANIFEST.detailed. If I understood the big picture better, I could be
more specific. In particular, I'm unsure how well the idea of a
single static MANIFEST.detailed list will scale. For example, in perl,
the number of generated files that get installed is very large. Not
only are there all the various extracted files (the *.PL files), there
are also all the autosplit files. To make matters worse, the exact
set of files is platform- and configuration-dependent, and can only
be produced after Configure has been run. I'd expect parrot
ultimately to have similar issues, if it doesn't already.
In the meantime, the recent MANIFEST-related changes have broken all
of my automatic build & test scripts, so at a minimum, perhaps it
shouldn't be fatal if the existing MANIFEST is read-only, as long as
it's accurate?
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> I created MANIFEST.detailed in order to create parrot RPMs. My idea
> was that MANIFEST by itself doesn't contain sufficient information to
> generate the RPMs (at the very least, you can't tell which file goes
> into which RPM). But in my experience, it's usually much more
> convenient to have a fully explicit listing of files for this sort of
> thing, but if you duplicate the information between MANIFEST and some
> other file, you'll never keep things in sync.
Oh, I agree absolutely.
> I was also assuming that any other packaging scheme would need similar
> sorts of metadata, and the MANIFEST.detailed gives an obvious place to
> hang the metadata off of.
> On the other hand, I didn't want to meddle with the existing tools
> that use the plain MANIFEST, so I thought I'd both generate MANIFEST
> and include it in the distribution. Ironically, this was to avoid the
> exact sort of automated build breakage that you're experiencing now.
> :-)
MANIFEST.detailed differs in two ways from MANIFEST:
1. The filename is in the second field instead of the first. This is
obviously a trivial difference, easily changed. One possibility might be
to put the filename in the first field. Then perl's existing MANIFEST
tools will deal with it correctly. Having extra metadata on the same line
as the filename is no problem for perl's existing MANIFEST tools.[*]
2. MANIFEST.detailed currently contains an incomplete list of files to be
installed. I say incomplete because it doesn't (and can't!) include all
configuration-dependent auto-generated files. For example, depending on
whether or not your system has a JIT, you might or might not have the
jit_emit.h header file. It might also then include some rule (e.g.
include/parrot/*) from which all auto-generated files could be determined.
> > In the meantime, the recent MANIFEST-related changes have broken all
> > of my automatic build & test scripts, so at a minimum, perhaps it
> > shouldn't be fatal if the existing MANIFEST is read-only, as long as
> > it's accurate?
> Seems reasonable.
Good. For now, that should be fine.
> Oh. Is that what you meant by read-only? So I can write to any file I
> want, as long as it's not part of the tarball?
Yes, sorry to not be clear. I use the MANIFEST to create a single
read-only copy of the source tree on an NFS server. I then use symlinks
to share that copy across several different machines. I can then run
multiple builds on the different machines. The source files are thus
read-only because I don't want different builds stomping on each other in
any way.
Actually, this wasn't originally my idea. A long time ago, the perl5
source tree was "self-modifying", and I got complaints from various users
that this caused problems, and have since been sensitized to the issue.
--
Andy Dougherty doug...@lafayette.edu
[*] Those MANIFEST tools are line-oriented, however, and I could conceive
of it later becoming necessary to have stuff on multiple lines, in which
case we might head towards some sort of MANIFEST.yaml meta-file shipped
with parrot. I suspect that's pretty far down the road, however, so it
makes sense to let perl5's Module::Build build up some experience in that
area before worrying about it.