New package: perl-MP3-Tag

[Michael Fleming]

On Sat, 2005-06-25 at 16:36 -0700, Chip Turner wrote:
> 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?

I'm building it now in mock, I'll give it a once-over when built and
post some findings to the list. I have a very vague recollection of
packaging this myself in the distant past for local usage, and there
wasn't that much to it :-)

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

My beefs were it's seeming inability to find / ignore dependent packages
(as specified in Makefile.PL for example) and feed them to
BuildRequires, plus the rather poor (almost non-)use of the %description
section and Summary (which is more often not just "FooPerl perl
module"). Perhaps being able to feed them a file for those sections
would be helpful and allow the packager to provide a little more detail.

I also agree that passing $RPM_BUILD_ROOT as part of the initial %build
section (as some of the autogenerated specs contain) is a recipe for
trouble in many cases. :-)

I've also compared the install sections of the Fedora perl template spec
vs. the cpanflute2 ones, the Fedora template strikes me as a little
simpler and cleaner (aiding the newb packager, or even the more
experienced but caffiene deprived one like me ;-))

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

Absolutely - there are useful modules out there that are so simple that
it would take more time to adjust a template manually than to build the
thing with an automated tool.

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

Hope the above is vaguely useful :-)

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

The 1% (possibly more, I've seen stuff I've built in the past that
cpanflute or cpan2rpm just chokes on) justifies the template IMVHO.
Additionally it gives the packager the extra flexibility plus a spec
that's a little simpler to maintain.

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

.... which is what I've tended to do in the past. cpanflute2 is REALLY
good at spitting out a nice and easy starter spec, but many would want
to massage the result for more complicated modules or a
simpler-to-manage build spec. Example - perl-Tk, which has been
discussed this week.

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

Half my kingdom for a Suggests!

ISTR a policy (perhaps not explicitly stated) of "build per the defaults
for the basic upstream package" which I roughly take to mean "Build
without passing any '--with-foo' or equivalent switches"

Then again, if the package strongly suggests adding it, it provides
useful additions and functionality and it's easily handled (ie the BR is
already there in Core/Extras and not too esoteric) then slot it into the
default spec, I say. In this case adding BR: perl-Compress-Zlib is a
no-brainer.

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

Doing it manually is as boring as hell, but occasionally needed. It is
of huge benefit to have something to handle the more "standard" modules
though.

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

I'm sure you'll get feedback from those of us who have/do package Perl
modules, plus I'm sure there's ideas in existing specs and templates
that can be used as ideas for improvements.

Michael.

-- 
Michael Fleming | Brisbane, Queensland, Australia
<mfleming at enlartenment.com> | http://www.enlartenment.com/
ICQ: 9150031 AIM: ausbofh MSN: aussiebofh at hotmail.com
"Bother" said the Borg, "We've assimilated Pooh!"