New package: perl-MP3-Tag

[Michael Schwendt]

On Sat, 25 Jun 2005 16:36:10 -0700, Chip Turner wrote:

> > > 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.

Well, look at all the generated stuff in the spec file! Even brp-compress
is called explicitly. Creation of file lists and things like that add
complexity and increase the spec file size, which leads to trouble when
you may need to fix things manually.

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

They ought to be "vendor" for Core, too. Site locations are for local
installations, e.g. directly from CPAN, as site locations come first
in @INC.
 
> > 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.

Then that is broken by design. The main "perl" package must not provide
"perl(:MODULE_COMPAT_5.8.6)" if it doesn't search in Perl 5.8.6-style
vendor/site locations.

> > 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?

My personal point of view here is that the result would be run-time
breakage. An MP3::Tag API user could require Compress::Zlib explicitly to
avoid run-time breakage. But that's easy to forget. Hence I prefer feature
completeness where no nice error handling is implemented.

> > 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?

Yes. As mentioned earlier, I usually focus on what ends up in the binary
packages and second to that, if the build setup is good. Spec formatting,
tabs/spaces and things like that don't interest me. Either you or me needs
to post the APPROVED message to fedora-extras-commits, though. Haven't
found the time to do that. Missing a script for that. ;)
 
> ..
> 
> On a general note, packaging perl modules by hand is a waste of time
> IMO.

Lots of argueing is a similar waste of time. We can get back to argueing
and seeking for solutions when things break badly.

-- 
Michael Schwendt <mschwendt at users.sf.net>
Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4
loadavg: 1.86 2.50 2.53