Re: More bioperl modules need packaging
On Thu, Nov 21, 2019 at 05:55:32PM +0000, Carnë Draug wrote:
> > 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.
Ahhhh, my fault. I mixed this up with other Ensembl projects without
any release tags. Just forget what I said. Using the last release tag
is always my prefered packaging option.
> 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.
I fully agree - I was just wrong.
So I keep the patch to get the package build but stick to the released
code.
Thanks a lot for double checking (and spending time for an extensive
explanation - I'll keep a copy of it in case I might need those good
arguments written down. ;-) )
Andreas.
--
http://fam-tille.de
Reply to: