incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject [lucy-dev] Maintaining manifest to avoid Module::Build warnings
Date Fri, 10 Dec 2010 18:36:42 GMT
On Fri, Dec 10, 2010 at 09:14:18AM -0600, Peter Karman wrote:
> If we always build a dist from a 'svn export' rather than a working dir.
> Or even a clean 'svn co', does this issue go away?

There's no problem with the CPAN dist tarball.  Since the Perl 'dist' action
involves creating a MANIFEST file, unpacking and building from the CPAN
tarball doesn't incur any warnings.

The problems occur when building from an SVN checkout, or building from the
(theoretical) official ASF tarball.  If you check out Lucy from SVN right now
and run Build.PL, you get output like this:

    marvin@smokey:~/projects/lucy/perl $ perl Build.PL 
    Creating new 'MYMETA.yml' with configuration results
    Can't find dist packages without a MANIFEST file
    Run 'Build manifest' to generate one

    WARNING: Possible missing or corrupt 'MANIFEST' file.
    Nothing to enter for 'provides' field in metafile.
    Creating new 'Build' script for 'Lucy' version '0.001000'
    marvin@smokey:~/projects/lucy/perl $ 

Since SVN is targeted only at developers, we can continue to live with the
warnings.  However, I don't think that it's kosher to show warnings like that
when building from the official ASF release.  To avoid them, we have to
provide a trunk/perl/MANIFEST file in the official dist, which leaves us with
two choices:

  1. Maintain trunk/perl/MANIFEST continuously.
  2. Create trunk/perl/MANIFEST as part of the ASF release process.

Per Hoss's recommendation, we're trying to keep the release generation process
to Jukka's ideal of "svn export | tar | gzip".  That suggests that we would go
to the trouble of maintaining trunk/perl/MANIFEST.  I'm OK with that -- we've
done it before -- but would like to make the process less labor intensive.

I think it will be possible to hack up something using a combination of svn
commands.  If "svn list -R" listed newly added files, then the following would
work great:

    svn list -R | sort > MANIFEST

Since that's not how "svn list -R" behaves, we'll have to come up with
something a little more involved, but it still will just be a short script we
can dump into trunk/devel/bin.

Marvin Humphrey


Mime
View raw message