https://bugzilla.redhat.com/show_bug.cgi?id=1788170 --- Comment #5 from Petr Pisar <ppisar@xxxxxxxxxx> --- (In reply to Sandro Mani from comment #4) > Thanks for your comments. Some questions, also in the interest of improving > my other perl packages: > You are doing very well. Your packages are almost perfect. > - How do you pick up all the BRs? Based on what I've learned so far, I'm > doing something like > > $ tangerine -c Makefile.PL <subdirs> > > and then omitting the dependencies only required by author tests. > Tangerine is a very good tool. I start with checking for a presence of common dependencies like perl-generators and perl(:MODULE_COMPAT...), then I read META.json or META.yml, then I scan Makefile.PL with tangerine. Then I read Makefile.PL as it sometimes contains very contrived code that can load of probe for other modules and scripts. Then I scan ./lib, then ./t or ./test.pl. Whenever I see a suspicious dependency or almost any non-trivial run-time loaded dependency in the output, I check the code to see whether the dependency is indeed needed. Then I also grep sources for 'eval' keyword to discover typically weak dependencies. I also grep sources for 'ENV' variable because especially tests tend to skip or perform some parts based on the environment variables. Then I read the spec file to see whether all executed commands (like 'make') are build-required. Special care is also devoted to bundled code in ./inc that I try to unbundle first. Then I build the package. Sometimes the test fails because of a missed dependency. That happened to me with the "blib" module here. blib module is now in perl-interpreter package, but I have locally a developmental perl that actually have it in a separate package that happened not to be installed. Then if there are some dependencies I'm not sure about their necessity, I will mangle their identifiers in the sources and run 'make test' on them to see what happens. Finally I compare the dependencies listed in the resulting binary package (rpm -q --requires ...) with those listed as BuildRequires. For that purpose I usually keep the dependencies for the packaged code and for the tests separated in the spec file. That eases the comparison. > - When do you decide to constrain a BR or run-time dependency? There are > typically version constraints for most requires in the various metadata > files. I usually follow the versions listed in metadata. Authors usually had a good reason for adding them there. But that's not always true. Some people or various release tools, like DistZilla, tend to write there versions from their current system. This case becomes obvious when rebasing a package to a new version. In that case you can see the versions changed to the latest version available on CPAN or changes without any reason (e.g. a new release changes only documentation, but there is a bump in a version of a dependency). The issue with specifying minimal versions is that those are usually historical versions that Fedora abandoned many releases ago. There is a good deal of packagers that do think that listing the versions is pointless because every supported Fedora contains them. Therefore I usually mark them as TODO in my reviews. It's also true that authors very often list the version in metadata without listing it in the sources ('use MODULE VERSION;'). Then the packaging becomes tedious because it requires writing a lot of lines for the packager (like the __requires_exlcude macro). On the other hand when somebody decides to port the package to an old EPEL, having the version in spec files becomes very handy because it reveals the incompatibility very early. > Wouldn't the package fail to build anyway if the requirement is not > met? The build should fail. (Although there are cases when the build script ignores the missing dependencies). But that does not prevent people from getting bitten at run-time. Imagine a code needs the latest Exporter. You build the package with it, the package gets installed to user's system, and then the user decides that he does not like the latest Exporter and downgrades perl-Exporter package. If the version constrain weren't specified for the run-time dependency, DNF would allow the user to get the system into a wrong state. It's true that Fedora users usually do not downgrade, partially because Fedora removes older packages from mirrors, but nevertheless the possibility is there. (E.g. a downgrade from updates-testing to updates Fedora repository. Or in RHEL where all historical packages are kept available indefinitly.) > - And specifically to > > - use Exporter qw(import); > + use Exporter 1.15 qw(import); > > How is this related to the >= 5.57 requirement? Oh, sorry. That's my mistake. There should be 'use Exporter 5.57 qw(import);'. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
