New package: perl-MP3-Tag

[Chip Turner]

On 6/25/05, Michael Schwendt <bugs.michael at gmx.net> wrote:
> On Sat, 25 Jun 2005 10:35:07 -0700, Chip Turner wrote:
> 
> > No love?
> 
> The CVS accounts system lists over hundred contributors, so surely reviews
> should not be done by always the same few people. Additionally, some of
> them have been at FUDCon 2, which has had its second day today, or are
> still on the way home from Karlsruhe.

Relax.  It was a playful ping in case it got lost in inboxes.

> > http://perl.pattern.net/perl-MP3-Tag-0.94-1.src.rpm
> 
> Those cpanflute2 auto-generated spec files are awful.

*chuckle* Good to find someone with opinions on the topic!  I'd love
some specifics so that I can improve cpanflute2 to meet fedora
packaging guidelines.  I went through a round of 'make cpanflute2
better' a month or two ago on, iirc, the fedora-perl list.  I'm sure
we all see the value in tools that can automatically create packages,
so I'm more than willing to improve cpanflute2/RPM-Specfile to achieve
that.  Of course, I do need specific feedback, and not vague words
like 'awful,' so if you have other specifics besides those below,
please do let me know.

> Now generally, I don't care that much about how a spec file looks if it
> creates a working package, with no issues in the binary rpm. But the
> package should install the files into Perl vendor locations, not site
> locations. [With Fedora perl spec template from the fedora-rpmdevtools
> package, which has been enhanced since its creation at fedora.us,
> packaging many Perl modules gets really easy.]

Ah, installdirs should be vendor for fedora-extras?  Okay, fixed.

As for specfile templates... interesting.  It strikes me as a waste of
time to have templates for packages that can so easily be
autogenerated in 99% of the cases, though.  What exactly does having a
template for perl modules provide that a tool like cpanflute2 doesn't?
 Besides the peculiar whitespace alignment.  Ideally, even for the 1%
exceptions, it would be better to start from a template properly
filled out via cpanflute2 with as many details as possible and let the
author improve from there.

> To have $RPM_BUILD_ROOT somewhere in %build is a mistake in 99.9%
> of the cases. Hardly any build process needs to know about paths
> into a buildroot. It only increases the possibility that buildroot
> paths end up in compiled code or files generated from templates.

Indeed, it's nice to not have it there, but until very recent versions
of perl/ExtUtils, it was necessary.  Rather a mess for a while,
especially with early perl 5.8.x's.  Also, are you sure what is in the
template will work with Module::Build's Makefile.PL emulation?  It has
some inconsistencies with Makefile.PL (destdir, not PREFIX, on the
Makefile.PL line).

> The package also lacks the versioned :MODULE_COMPAT dependency, which is
> your invention, IIRC. Particularly useful if you want to make sure a newer
> Perl version still has the used vendor locations in its module search
> path.

Unfortunately, MODULE_COMPAT doesn't quite provide that guarantee; all
it provides is a statement that the module should work on 5.8.6 (and
anything thereafter, assuming, say, some of the MODULE_COMPATs don't
get dropped from perl.spec, which happens if binary incompatibilities
pop up).  It doesn't provide any guarantees about vendor_perl or
site_perl or any of that.

> "make test" should go into the %check section.

Hmm.  That's a bit of an rpm-4.2ism.  I generally want to keep
cpanflute2/RPM-Specfile working properly with as many perl's and rpm's
as possible.  Effectively, if cpanflute2 were to start generating that
requirement, then RHEL 2.1 would no longer work correctly, I believe,
but all supported FCs would.  I need to think a bit more about
breaking that compatibility.

> ID3v2 support accesses Compress::Zlib, but no dependency on
> perl-Compress-Zlib is seen.

It's optional and not required for the majority of module
functionality, so I would argue it isn't actually a requirement.  Too
bad RPM doesn't support Suggests (it's only been, oh, four years since
I first started asking for that functionality, alas).  Is there a
stated FE policy on optional behavior vs mandantory package
requirements?

> Feel free to import into CVS and give the package some love there.

Well, I was following the guidelines on the NewPackageProcess wiki
before importing; does this constitute formal approval?

..

On a general note, packaging perl modules by hand is a waste of time
IMO.  It's rote and error-prone and 99% of the time totally mechanical
and requiring no thought.  That's why cpanflute2 exists.  As it stands
right now, FC/FE is the only thing I'm interested in targetting with
cpanflute2 in terms of adherence to packing standards and such, so any
feedback about making cpanflute2 produce packages more suitable for
Fedora is welcome.  My main constraint is not arbitrarily breaking
backwards compatibility, but I'm willing to in most cases if backwards
is "old" enough.

Ultimately the goal is simpler, more reliable packaging of perl
modules to facilitate an even more robust perl presence in FC/FE.

Chip

-- 
Chip Turner                   chip.turner at gmail.com