Bug 234861 - Review Request: perl-Mail-Transport-Dbx - Parse Outlook Express mailboxe
Review Request: perl-Mail-Transport-Dbx - Parse Outlook Express mailboxe
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Parag AN(पराग)
Fedora Package Reviews List
:
Depends On:
Blocks: perl-Mail-Box
  Show dependency treegraph
 
Reported: 2007-04-02 13:04 EDT by Tom "spot" Callaway
Modified: 2015-10-15 07:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-09 13:15:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
panemade: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Tom "spot" Callaway 2007-04-02 13:04:35 EDT
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).
Comment 1 Parag AN(पराग) 2007-04-05 00:23:09 EDT
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.
Comment 2 Ralf Corsepius 2007-04-05 00:53:29 EDT
Missing:
BR: perl(Test::Pod)
BR: perl(Test::Pod::Coverage)
Comment 3 Parag AN(पराग) 2007-04-05 01:14:17 EDT
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."
Comment 4 Ralf Corsepius 2007-04-05 02:06:32 EDT
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.
Comment 5 Parag AN(पराग) 2007-04-05 02:16:19 EDT
(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.
Comment 6 Ralf Corsepius 2007-04-05 03:21:23 EDT
(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.

Comment 7 Tom "spot" Callaway 2007-04-09 09:59:39 EDT
New Package CVS Request
=======================
Package Name: perl-Mail-Transport-Dbx
Short Description: Parse Outlook Express mailboxes
Owners: tcallawa@redhat.com
Branches: FC-5 FC-6
InitialCC: fedora-perl-devel-list@redhat.com
Comment 8 Tom "spot" Callaway 2007-04-09 13:15:16 EDT
Built.
Comment 9 Petr Pisar 2015-10-15 07:52:29 EDT
This package bundles libdbx <https://sourceforge.net/projects/ol2mbox/files/LibDBX/>.

Note You need to log in before you can comment on or make changes to this bug.