New package: perl-MP3-Tag

[Chip Turner]

On 6/25/05, Michael Fleming <mfleming at enlartenment.com> wrote:
> 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 :-)

Thanks!

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

These  are all Hard Problems(tm) to solve, really.  Short of parsing a
perl script (Makefile.PL), it isn't really doable to figure out the
correct BuildRequires.  Makefile.PL, which lists them, is just a perl
script, and the portion that specified the requires is just a hash. 
Unpleasant to parse.  cpan2rpm does Evil and Nasty things involving
munging Makefile.PL and actually executing it.  I don't want to go
down that path.  cpanflute2 is intended to make the easy cases trivial
and give you a leg up on the hard cases.  It doesn't solve every
problem but it does get you most of the way. The description and
summary are also hard; the data isn't really structured that way and
extracting it would not be terribly easy.

What it comes down to is that cpanflute2 should, in my mind, spit out
a specfile/srpm that above all works and isn't "awful."  It can't spit
out one completely ready for, say, fedora extras or for fedora core,
but hopefully it will get you darn close.

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

No argument -- just history required it.  I've removed it from my svn
copy of RPM-Specfile, though, as well as a number of other changes
that should result in more adherence to fedora extras conventions. 
I'll post a changelog when I'm done, as well as redo MP3::Tag with the
new version.

> 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 ;-))

Yes, it is more complicated... but it is more thorough.  cpanflute2
automatically builds the file list to ensure everything that 'make
install' puts somewhere (minus some files it purposely removes) get
placed in the RPM.  This is a good thing.  Most, but not all, perl
modules just drop things in _mandir and perl_vendor{arch,lib}.  But
some drop files in etc, and even more drop executable scripts in
/usr/bin.  I'm fairly confident in how cpanflute2 does this as the
code has been in use (and improved by community members) for years and
years.  I've simplified some of it, but all can't be removed, even
with the latest rpm and perl.

This question comes down to managing the %files section.  I've found
historically that just letting a script do it is less error-prone over
time.  cpanflute2 will -never- miss a file; the template might. 
Either way, a user will have to deal with things when they break, but
the code in cpanflute2 has had a lot of exercising, and speaking from
experience, it has paid off to have it there.

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

Yep, I agree.  Mainly, for a fedora package, my hope is 99% of modules
are 'run cpanflute2, fix up the summary/description/license, and
submit to fedora-extras-list.'  I think it's pretty close to that now.

> >  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 :-)

Most definitely.

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

I've modified cpanflute2 to offer a 'just spit the spec file out'
mode.  Hopefully that will ultimately prove more useful than a
completely generic, static file.

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

In this case, the dependency is not explicit -- in fact, it seems as
though it once was listed explicitly in Makefile.PL but was then
commented out.  I suspect that compressed sections of id3v2 tags are
fairly rare.  The compress code isn't hit in 'make test' for the
module, so it definitely isn't a BuildRequires... it may be a
Requires, but not a BR.  Since Compress-Zlib is in core, I don't care
one way or another for making it a regular Requires, though if it
weren't, in this case, I wouldn't add it as a separate RPM.

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

Much appreciated.  I'll have a new RPM-Specfile sometime after the
feedback stops coming in that hopefully will improve on its relevance
for fedora-extras.

Chip

-- 
Chip Turner                   chip.turner at gmail.com