Re: More bioperl modules need packaging

[Carnë Draug <carandraug+dev@gmail.com>]

On Thu, 21 Nov 2019 at 17:15, Andreas Tille <andreas@an3as.eu> wrote:
> On Thu, Nov 21, 2019 at 03:26:40PM +0000, Carnė Draug wrote:
> > I also changed some others things that you may have different opinion
> > of.
>
> I'm wondering about pointing the watch file to CPAN.  While I definitely
> agree that versioned releases would be great and should show up on CPAN
> upstream does not seem to do this.  Github is way more recent which I
> noticed when I imported the version from CPAN (to match your watch file
> suggestion).  This leaded to the same failure as before and I needed to
> provide the latest Build.PL from Github as quilt patch to be able to
> build the package.
>
> This makes me wonder in how far it is a good idea to rely on CPAN if
> upstream is just not caring about proper releases.  Any opinions?

Upstream seems to be making CPAN releases, at least the latest version
number is the same in both metacpan and github.  If I understood you
correctly, the issue is that upstream botches their CPAN releases.

Here's some reasons why I would still favour the stuff on CPAN:

1. Github provides snaphots of the repository.  While a snapshot of
   the repository can be equal to a release they are not the release
   itself (even if github calls them releases).  Depending on the
   release process, some files may be created or removed to create the
   actual release file.  For example, the Makefile.PL and Build.PL
   files are sometimes created during the release and will not appear
   in the repo snapshot.

2. Other users installing packages with perl tools to manage modules
   will be installing from CPAN not from github.  If someone told me
   they used version X and I had to replicate it, I would guess they
   meant the version from CPAN not the one tagged as such on the
   upstream repository.

3. Upstream can change the location of, or even remove, its
   repository.  Upstream can also force push changes to the repo and
   modify tags.  If I had to choose, I would bet on CPAN releases
   being more persistent.

4. I know upstream sometimes botch their releases.  But it goes both
   ways.  I am also familiar with cases where upstream forgets to add
   files under version control.  Those extra files appear on the
   released package but not the repository.  If problems can be in
   both places, then I think it's the release that counts.  It's on
   the name.