Tarballs and zips on the GitHub release page do not include Makefile.PL

[joncampbell123]

Most Perl modules can be compiled and installed through Makefile.PL, but this project doesn't have it anymore.

How do you make && make install?

If you're not going to use Makefile.PL, then you need to provide INSTALL instructions.

[skaji]

You should install modules from CPAN.
https://cpan.metacpan.org/authors/id/O/OA/OALDERS/URI-5.09.tar.gz

[joncampbell123]

CPAN requires internet access to install. This is for a build script explicitly designed to run offline. How do I "make" and "make install" your code?

[skaji]

Download https://cpan.metacpan.org/authors/id/O/OA/OALDERS/URI-5.09.tar.gz in a machine that has internet access.
And copy the tarball to the target machine, and untar/build/install the module.

[petdance]

The steps are as follows. Same as any CPAN module unless otherwise stated:

wget https://cpan.metacpan.org/authors/id/O/OA/OALDERS/URI-5.09.tar.gz
tar zxvf URI-5.09.tar.gz
cd URI-5.09
perl Makefile.PL
make
make test
sudo make install

[joncampbell123]

I see. Why don't your releases have a Makefile.PL?

[petdance]

I see. Why don't your releases have a Makefile.PL?

URI does indeed include a Makefile.PL. See my instructions above.

[petdance]

If you have a URI tarball that does not have a Makefile.PL in it, please include a link of where you got it from so we can look into how that happened.

[joncampbell123]

Here you go:

https://github.com/libwww-perl/URI/releases

I checked each one. Makefile.PL seems to have disappeared after 1.71.

[petdance]

I have changed the title of this issue to clarify what the real issue is.

[joncampbell123]

Thank you. Others who build Linux from Scratch will also appreciate this.

[thoke]

I'm not shocked that the GH Release doesn't contain Makefile.pl, this is a dist.ini based package and there isn't a Makefile.PL as part of the repo.

[karenetheridge]

Github's "releases" aren't really releases, but just snapshots of tags. They aren't meant to be installable as-is. The actual installable distribution is uploaded to cpan.

[petdance]

Maybe we should get rid of the "releases". I don't see a way to do that, though.

Somehow we should have something so that folks don't get confused.

[karenetheridge]

Yes, it's quite unfortunate.

[petdance]

We can manually individual releases.

Go to an individual release page and there's a big red Delete button in the upper right.

[joncampbell123]

That's a bit over the top, don't you think?

If you're not going to provide a Makefile.PL with each release, then at least document in the README how to generate a Makefile.PL for us Linux from Scratch types.

[joncampbell123]

I can think of plenty of automake-based projects where the tarball does not provide a configure script, but provides an autogen.sh and configure.ac for you to generate the configure script. Easy enough, just "apt get install" or whatever "m4, automake, autoconf" and then run autogen.sh. All you need to do is document that process.

[joncampbell123]

If CPAN is the only way to obtain a release that you can actually make && make install you actually make it more difficult for others to compile and develop your code or make improvements in a branch because, well, how do you install your version to test it?

I would have a lot less help with DOSBox-X if I took away the configure script and demanded that everyone (including Windows developers!) figure out on their own how to compile, make. and make install.

[genio]

I go through a manual process on each release that puts the generated tarball in as an asset: https://github.com/p5-UV/Alien-libuv/releases for an example.

It's an extra step to edit the tag to make it a release, add the changelog there, and include the tarball. However, I feel like it's useful and helps people who navigate by GitHub rather than metacpan

[genio]

I keep threatening to make a dzil plugin to do that but haven't gotten there yet.

[genio]

@joncampbell123 I'm not trying to minimize your point here, but we have solved that problem quite some time ago with our Perl module installers.

The typical way to install things has pretty well steered towards cpanm or cpm these days.

wget https://cpan.metacpan.org/authors/id/O/OA/OALDERS/URI-5.09.tar.gz
cpanm URI-5.09.tar.gz

or even just

cpanm https://cpan.metacpan.org/authors/id/O/OA/OALDERS/URI-5.09.tar.gz

or

cpanm URI

In that scenario, the Perl module installer cpanm handles all of the untarring, finding the compiler for Perl, running the installation process (along with prereqs, etc.).

https://www.metacpan.org is THE way to find your modules and cpanm/cpm help you install those modules (on windows and linux).

Also check out carton for building and exporting an app.

[petdance]

That's a bit over the top, don't you think?

No, I don't, or I wouldn't have suggested it.

All you need to do is .l.l.

The releases that Github autogenerates are an unwanted artifact. I wasn't even aware of them until this issue came up and you provided a link to the releases page. I don't think it makes sense to do work to make the unwanted artifacts usable.

[oalders]

To be honest, until this issue came up, I didn't even realize that GitHub was creating releases from the tags. If we really wanted to create the tarballs ourselves, it looks like we could use a GitHub action like this: https://github.com/marvinpinto/action-automatic-releases

However, we'd be jumping through hoops in order to provide what is already available on CPAN.

Having said that, there is information in https://github.com/libwww-perl/URI/blob/master/CONTRIBUTING.md on how to use Dist::Zilla to generate all of the files which belong in a release.

[karenetheridge]

However, we'd be jumping through hoops in order to provide what is already available on CPAN.

Agreed. Also, what's at the master branch is not necessarily releasable, and it would be deceptive to file bug reports against a particular version when the code containing a particular $VERSION declaration isn't actually the same as the release for that version (some people bump $VERSION immediately after a release, and some do it immediately before.. or somewhere in the middle of the development process).

Conceivably there could be an automated process which copied the release tarball to the github releases page, which would ensure that it matched the release on cpan. But an easier thing to do would be to have a note in a documentation file that indicated that cpan is the canonical location for the release and the github files should not be relied upon.

[joncampbell123]

@karenetheridge But, if someone should choose to compile from source on this repo, it would help if what @oalders posted were in a README or INSTALL file on how to use Dist::Zilla to generate the files needed as well.

[Grinnz]

Unless you are contributing to the module (in which case you could find such information in CONTRIBUTING.md for instance) you should not be generating your own release files, but instead using the release tarballs from CPAN.

[petdance]

you should not be generating your own release files, but instead using the release tarballs from CPAN.

Which leads me back to suggesting that we delete the releases that are autogenerated.

If we had deleted these unwanted artifacts in the first place (if we had realized they were getting created), then their existence wouldn't have misled @joncampbell123 into thinking that he should be building from them.

[Grinnz]

FWIW I use the InstallGuide plugin to provide an INSTALL file for the cpan tarball and repository, though it is not really designed for github and so doesn't describe how to retrieve the tarball manually from CPAN. Perhaps something that could be improved.

[karenetheridge]

Which leads me back to suggesting that we delete the releases that are autogenerated.

I searched through the github docs a bit and I didn't find a way of preventing these from being automatically created. :/

[Grinnz]

I opened karenetheridge/Dist-Zilla-Plugin-InstallGuide#1 to include some information about this in InstallGuide. @joncampbell123 would this have helped point you in the right direction?

[joncampbell123]

That's fine, but I'm also asking if the install guide can describe how to use Dist::Zilla to generate a Makefile.PL if I should choose to instead git clone from this repo or use one of GitHub's release tarballs.

[Grinnz]

It cannot, since this is not a supported installation method for users.

[petdance]

I searched through the github docs a bit and I didn't find a way of preventing these from being automatically created. :/

I understand. I couldn't find a way either. I still suggest that it would be worth deleting them manually to avoid confusing users.

[karenetheridge]

There is often a CONTRIBUTING{.md}? file in the repository that explains how to build and test the distribution from source, but again that usecase is intended for development, not for installation.

[karenetheridge]

@genio suggested on irc that it might be possible to set up a github action that deleted the release. We'll look into that.