Description of problem: z88dk.spec should BuildRequire: these perl-dists: perl(Capture::Tiny) perl(Data::Dump) perl(File::Basename) perl(File::Spec) perl(IO::File) perl(Iterator::Simple) perl(Iterator::Simple::Lookahead) perl(Regexp::Common) perl(integer) perl(strict) perl(warnings) Version-Release number of selected component (if applicable): Additional info: - BR:'ing these, makes hidden run-time deps explicit at build-time and causes builds to abort early in case of changes to perl packaging. This helps avoiding packing mistakes like these: From https://lists.fedoraproject.org/pipermail/devel/2015-September/214042.html: [z88dk] z88dk-1.10.1-8.20150709cvs.fc23.i686 requires perl(Iterator::Simple::Lookahead) z88dk-1.10.1-8.20150709cvs.fc23.i686 requires perl(Iterator::Simple)
BuildRequiring runtime-only requirements makes no sense whatsoever.
(In reply to Kevin Kofler from comment #1) > BuildRequiring runtime-only requirements makes no sense whatsoever. With all due respect, I disagree. What I outlined above is Fedora perl packaging standard. What you do is careless and unsafe packaging.
This is MY package. I am NOT going to add BuildRequires that are completely unnecessary and would thus make builds slower for no good reason. Runtime requirements belong into Requires (or Recommends/Suggests), not BuildRequires.
I'll also add that the missing runtime dependency is caught just fine by the routine broken dependency checks, which is how you found out about it to begin with. I don't see what having the package also FTBFS would improve. I also don't know how I would get the list of Perl modules to BuildRequire even if I wanted to. Do you think I should build the package, take the auto-Requires, then rebuild the package with the auto-Requires copied to BuildRequires? Sorry, but no.
Then let me put it this way: 1. Your package's configuration is broken. Its configuration does not check all necessary requirements. 2. Due to 1 your have pushed broken builds to Fedora. 3. You apparent refuse to do your job.
(In reply to Kevin Kofler from comment #4) > I also don't know how I would get the list of Perl modules to BuildRequire > even if I wanted to. Do you think I should build the package, take the > auto-Requires, then rebuild the package with the auto-Requires copied to > BuildRequires? Exactly, that's one commona short-cut/heuristics to find these deps. The actual way to do so would be to examine the source code, similar as you would do for #includes in c/c++.
> Then let me put it this way: > > 1. Your package's configuration is broken. Its configuration does not check > all necessary requirements. Nonsense. It's checking runtime requirements at build time that's broken (I always complain when upstreams do that, and the other KDE SIG packagers do, too), z88dk upstream is doing the right thing. And either way, it's an upstream issue. > 2. Due to 1 your have pushed broken builds to Fedora. I wasn't even aware that there are any Perl modules required at all. How was I supposed to add the (bogus) BuildRequires? > 3. You apparent refuse to do your job. I refuse to do a change that's obviously incorrect just because you ask for it. > Exactly, that's one commona short-cut/heuristics to find these deps. That means I have to do twice the work to maintain the package (just to add bogus dependencies). Please quit reopening this bug. If you think you can do a better job than me at maintaining z88dk, then for all I care you can have the package, but then it's yours to deal with. Just be warned that the Perl piece is only a very small piece, it's mostly C code. If you don't want the responsibility, then please accept that it's my package, not yours.
And next time, I'll know to check the runtime requirements. I don't need them as bogus BuildRequires for that. I'll also point out that z88dk was updated to a new snapshot in a rush because it was failing to build for months and we were given a notice of less than a week that longstanding FTBFS bugs need to be fixed lest the package be dropped, and also because of a licensing issue that I've been ignoring for way too long. (I had been waiting for a new upstream release with those 2 important fixes, but they haven't done one for years now, so I was forced to take a snapshot.) Documentation of the new dependencies was either not there or I didn't find it due to being in a hurry.