Spec URL: http://www.auroralinux.org/people/spot/review/perl-Mail-Transport-Dbx.spec SRPM URL: http://www.auroralinux.org/people/spot/review/perl-Mail-Transport-Dbx-0.07-1.src.rpm Description: Mail::Transport::Dbx is a wrapper around libdbx to read Outlook Express mailboxes (more commonly known as .dbx files).
Review: + package builds in mock (development i386). + rpmlint is silent for SRPM and for RPM. + source files match upstream url 4dcf5346a67c0a7f861cb2bb51a7d14e Mail-Transport-Dbx-0.07.tar.gz + package meets naming and packaging guidelines. + specfile is properly named, is cleanly written + Spec file is written in American English. + Spec file is legible. + dist tag is present. + build root is correct. + license is open source-compatible. + License text is included in package. + %doc is present. + BuildRequires are proper. + %clean is present. + package installed properly. + Macro use appears rather consistent. + Package contains code, not content. + no headers or static libraries. + no .pc file present. + no -devel subpackage + no .la files. + no translations are available + Does owns the directories it creates. + no scriptlets present. + no duplicates in %files. + file permissions are appropriate. + make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/0_pod.............skipped all skipped: Test::Pod not installed t/0_pod_coverage....skipped all skipped: Test::Pod::Coverage not installed t/1.................ok t/2.................ok t/3.................ok t/fixed.............ok All tests successful, 2 tests skipped. Files=6, Tests=58, 1 wallclock secs ( 0.12 cusr + 0.03 csys = 0.15 CPU) + Provides: Dbx.so perl(Mail::Transport::Dbx) = 0.07 APPROVED.
Missing: BR: perl(Test::Pod) BR: perl(Test::Pod::Coverage)
Ralf, I am really confused on make test issues. Can you please give me guidelines for future perl-* packages review about if I got something skipped in make test then whether I should ask submitter to add those as BRs ot it can be made as optional? Really wonder about perl packages that make will not require or asks those BRs but make tests asks about that. PS. Would like to say "Parag is not a Good Perl Programmer though he knows introductory perl programming."
Parag, I don't understand what you don't understand: Your log shows this: t/0_pod.............skipped all skipped: Test::Pod not installed t/0_pod_coverage....skipped all skipped: Test::Pod::Coverage not installed This means, the tests have not been fully excercised, because some optional modules were missing when building. Note: These modules are optional. So far, it has been our policy to "test to the maximum, when possible" (In practice, inside of the buildsys, i.e. everything but network access or some cases of database access) I.e. to let the testsuite excercise these checks, you'd have to BR: these tests' infrastructure. > Really wonder about perl packages that make will > not require or asks those BRs but make tests asks about that. I don't fully understand what you are trying to say, the principle of most perl modules' testsuites (and most testsuites in general), is to run "non-interactive, non-supervised" and only warn about those cases when something is missing. I.e. if you want larger test coverage but some "minimal tests", you'll have to configure a testsuite and your system in advance to running it. In case of a perl module, these BR: ... means to "taylor the system for the testsuite" in advance to running a testsuite.
(In reply to comment #4) > Parag, I don't understand what you don't understand: > > Your log shows this: > > t/0_pod.............skipped > all skipped: Test::Pod not installed > t/0_pod_coverage....skipped > all skipped: Test::Pod::Coverage not installed > > This means, the tests have not been fully excercised, because some optional > modules were missing when building. > > Note: These modules are optional. So after we create SPEC for any new perl package, we need to run "make test" to its maximum to check for whether we are missing any optional modules for this package or not and if we are missing anything then add those required packages as BR to SPEC. > > So far, it has been our policy to "test to the maximum, when possible" (In > practice, inside of the buildsys, i.e. everything but network access or some > cases of database access) > > I.e. to let the testsuite excercise these checks, you'd have to BR: these tests' > infrastructure. Ok. So this is main thing I should remember for reviewing now any perl-* packages. > > > Really wonder about perl packages that make will > > not require or asks those BRs but make tests asks about that. > I don't fully understand what you are trying to say, the principle of most perl > modules' testsuites (and most testsuites in general), is to run > "non-interactive, non-supervised" and only warn about those cases when something > is missing. > > I.e. if you want larger test coverage but some "minimal tests", you'll have to > configure a testsuite and your system in advance to running it. In case of a > perl module, these BR: ... means to "taylor the system for the testsuite" in > advance to running a testsuite. What my basic question is towards perl-* packages/its packaging is that in most of normal packages that uses gcc compilation uses ./configure and from there also we can know if we are missing to add any packages as BRs. But I am not able to find same for perl packages. Instead I saw "make test" is the only one way to satisfy package's all requires Build time dependencies. Now I got that. thanks for your reply. Tom, Either you can submit a new package to review again or you can add those BRs at a time of package importing in CVS.
(In reply to comment #5) > (In reply to comment #4) > What my basic question is towards perl-* packages/its packaging is that in > most of normal packages that uses gcc compilation uses ./configure These are configuration-time options (If "found" then "activate/build-in a feature") > and from > there also we can know if we are missing to add any packages as BRs. But I am > not able to find same for perl packages. Instead I saw "make test" is the only > one way to satisfy package's all requires Build time dependencies. ... and these are run-time options (run-time of the test-suites) The former rarely exist for perl-packages (Nevertheless, they occasionally they exist), while the latter also occasionally exist for "ordinary packages" (but most packages don't ship a testsuite) The problems actually are: * rpm doesn't destinguish between both situations. * Most packages do not properly destinguish between both cases. In practice, packagers have to resort to a "compromise that works", which in most cases will be "activate a testsuite only if it doesn't pull in additional configuration-time deps". In most cases, such as most perl-packages, "activating the testsuite" will not have negative impacts on package deps, but that's an item to be carefully watched for.
New Package CVS Request ======================= Package Name: perl-Mail-Transport-Dbx Short Description: Parse Outlook Express mailboxes Owners: tcallawa Branches: FC-5 FC-6 InitialCC: fedora-perl-devel-list
Built.
This package bundles libdbx <https://sourceforge.net/projects/ol2mbox/files/LibDBX/>.