[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: New package: perl-MP3-Tag
- From: Michael Fleming <mfleming enlartenment com>
- To: fedora-extras-list redhat com
- Subject: Re: New package: perl-MP3-Tag
- Date: Sun, 26 Jun 2005 10:24:11 +1000
On Sat, 2005-06-25 at 16:36 -0700, Chip Turner wrote:
> On 6/25/05, Michael Schwendt <bugs michael 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
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
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
> > 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
> 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 Fleming | Brisbane, Queensland, Australia
<mfleming enlartenment com> | http://www.enlartenment.com/
ICQ: 9150031 AIM: ausbofh MSN: aussiebofh hotmail com
"Bother" said the Borg, "We've assimilated Pooh!"
[Date Prev][Date Next] [Thread Prev][Thread Next]