New package: perl-MP3-Tag

[Michael Schwendt]

On Sat, 25 Jun 2005 20:08:49 -0700, Chip Turner wrote:

> > > 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.
> 
> No argument about Core -- it is the vendor.  But Extras is less
> obvious.  It isn't the vendor of the OS.  It isn't a site issue,
> either.  It's in-between.

We do not have anything "in-between" where we could install the Perl
modules. Therefore we choose the more appropriate location. And that is
"vendor". In particular, since Fedora Extras is a part of the Fedora
Project, its packages supplement the OS, and its enabled by default since
FC4 which makes them available to Yum just like core OS packages. These
Perl packages must not be treated differently when installed as a
dependency and e.g. must not override user's manually installed
modules. The decision to override OS packages via site installations
should remain the user's. The local admin decides when to break things
with unofficial updates/upgrades done locally. We don't.

> > Lots of argueing is a similar waste of time. We can get back to argueing
> > and seeking for solutions when things break badly.
> 
> No disagreement there, but don't throw around words like 'awful' and
> red-flag things you see as brokenness but actually aren't. 

Did I declare any of the cpanflute2 bloat as blocker criteria? No.
Nevertheless I point out what I don't like, and that includes potential
breakage, such as specifying the buildroot in %build. It's something which
needs a second look. A reviewer would not like to approve a package, where
a buildroot path ends up in the binary package. Be aware that because of
spec file bloat, there are packagers, who would either not take a look at
your package at all, or Perl packagers, who would suggest major changes
which aim at spec file beautiness and perfection (avoiding compiler flags
in a noarch package). 

We have to live with the reviewing process prior to a first release. Where
less reviewing is applied or where packages are rushed into the
repository, it breaks things quickly and regularly. Just query bugzilla
for such issues (inaccessible directories or files, missing files,
non-working builds, completely untested builds, e.g. x86_64/ppc -- the
range of issues is broad). But in the end, _you_ are the package
owner. You should want to provide a package, which works fine and which
has low maintenance costs. The maintenance costs may increase
dramaticially, however, if you are absent and somebody may need to take
over your auto-generated spec(s), even if just temporarily. Hence my
introductory comment on whether I like auto-generated Perl spec files.
Hope that makes my point of view a bit more clear.

-- 
Michael Schwendt <mschwendt at users.sf.net>
Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1383_FC5
loadavg: 1.01 1.05 0.64