https://bugzilla.redhat.com/show_bug.cgi?id=1195573
--- Comment #8 from Petr Šabata psabata@redhat.com --- (In reply to Ben Boeckel from comment #7)
(In reply to Petr Šabata from comment #6)
- I would use the release URL instead of just pointing to the commit (which
could be something entirely different and nobody will notice). For example https://github.com/s-aska/%%7Bname%7D/archive/%%7Bversion%7D.tar.gz should work just fine. The tarball filename will be just the version plus extension but that doesn't really matter.
Indeed. Let me quote your link:
"If the upstream does not create tarballs for releases, you can use this mechanism to produce them. If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages."
Your upstream provides tarballs. https://github.com/s-aska/dropbox-api-command/releases
- Missing buildtime dependencies: perl, perl(CPAN::Meta),
perl(CPAN::Meta::Prereqs), perl(File::Basename), perl(File::Spec), perl(strict), perl(utf8), perl(warnings)
Hmm. Is there a way to detect these automatically? I think perl(WebService::Dropbox) also necessary. Or is that just a runtime dep? I'm not all that well-versed in Perl stuff.
Yes, perl(WebService::Dropbox) is just a runtime dependency and is generated automatically by rpmbuild (via perl-generators). It's required by script/dropbox-api which isn't used neither during %build nor %check phases.
You can use the `tangerine' command (from perl-Tangerine) to check perl files for what modules they provide or require. For example in your case, to see buildtime deps you could run `tangerine Build.PL lib t'.
perl-devel@lists.fedoraproject.org