Support for source based packages

[NicholasBHubbard]

This PR is not meant to be merged!

This a prototype showing that FPM can support source based packages (#1954) with the purpose of furthering the discussion. This PR almost certainly contains bugs and is not feature complete in terms of producing SRPM's.

Given the following recipe:

[download]
https://cpan.metacpan.org/authors/id/E/ET/ETHER/File-Temp-0.2311.tar.gz

[build]
perl Makefile.pl
make
make test

[install]
make install

If we run the command:

bundle exec fpm --workdir $WORKDIR -t srpm -s cpan -r $RECIPE_DIR/recipe File::Temp

We get a SRPM with the following spec file:

Name: perl-File-Temp
Version: 0.2311
License: perl_5
Release: 1
Url: https://cpan.metacpan.org/authors/id/E/ET/ETHER/File-Temp-0.2311.tar.gz

Source0: https://cpan.metacpan.org/authors/id/E/ET/ETHER/File-Temp-0.2311.tar.gz

Summary: return name and handle of a temporary file safely

%description
return name and handle of a temporary file safely

%build
perl Makefile.pl
make
make test

%install
make install

[jordansissel]

I'd like to dig deeper on the 'recipe' concept. I'm feeling like this concept shouldn't be necessary for most input types and, instead, fpm could be taught how to do this.

Comparing an RPM SPEC to fpm, the difference is pretty large. With fpm, almost everything is automated -- you don't need to know how where to download the source, what steps are required to build/install, nor where things should install. In many cases, you don't even need to know how to find what the dependencies are. Contrast to SPEC files, for every single SPEC, you have to write the build steps, source file locations, dependencies, etc, and none of this is automated.

If we follow this recipe approach, the automation parts of fpm get lost and replaced by write-everything-by-hand which in most cases is a lot of copy-pasting. By way of example, we can compare the steps required to use this example and create a second example to package Regexp::Common.

For these recipes, we can copy the existing File::Temp recipe and make the following modifications:

• We must change the Name field
• We must look up the correct URL for the source files as hosted on CPAN
• We must look up the correct version we want to use
• We must write our own %description and Summary fields

Likely unchanged:

• The %build and %install steps are likely unchanged

In practice, it feels like these recipes would require the same cognitive and source control burdens as rpm spec files, and I'd like to have fpm reduce cognitive loads where possible.

If we compare this experience to fpm's general use, a user wanting to package File::Temp can use a nearly identical command-line for any other Perl module, such as:

• fpm -s cpan -t deb File::Temp
• fpm -s cpan -t deb Regexp::Common

In both of the above cases, fpm defaults to the "latest" version and inspects the cpan content to determine the package name, version number, dependencies, description, etc. Note how few changes are required in the above example as compared to the recipe example.

If we think about extending fpm to buildable (with 'standard tooling'[1]) source package formats like SRPM, then I would expect that something like the following should produce an SRPM, given some hypothetical code implementation that makes this work:

• fpm -s cpan -t srpm File::Temp
• fpm -s cpan -t srpm Regexp::Common

I don't think a recipe should be required in these kinds of cases where fpm could be taught this knowledge.

[1] 'standard tooling' refers to whatever the common platform tools for building packages are, such as rpmbuild --rebuild or debuild

[jordansissel]

I forgot to say -- thanks for working on this prototype! It helps me understand what kind of user interface and experience (recipes, new flags, etc) you're thinking about.

[NicholasBHubbard]

Deprecated in favor of the #1967/#1972 prototype