[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New package: perl-MP3-Tag

On 6/25/05, Michael Schwendt <bugs michael gmx net> wrote:

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

brp-compress HAS to be called explicitly when you build a %files
section programmatically, otherwise rpm doesn't find the resulting

As mentioned in another thread, the programmatic file list code works
rather well and is more general than the few directories listed in the
template.  It does add some complexity, but in reality it is only
around ten lines of shell and, trust me, when packaging a perl module
goes bad, it's not those ten lines that are the problem.

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

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

*sigh* No, it isn't broken by design.  It comes from a time BEFORE
vendor_lib and site_lib were clearly defined.  Things evolved over
time.  But given that I suspect site_lib and vendor_lib would never
disappear, it is sufficient.

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

Depends on how likely the runtime breakage is.  There are a number of
packages in Core and maybe Extras where dependencies are "whited out"
-- meaning there is some perl script that requires some obscure
module, but for practical purposes it isn't needed for proper package
functionality.  This is a similar case -- compressed id3 tags are a
bit rare.  Adding a requires is trivial, though, and I have no strong
preference; I'll see if there is a general consensus either way on the
matter and follow it.

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

Cool, thanks.  I'll let you send the APPROVED since you approved it
and this is my first FE package.  Hold off, though, til I send through
the next version -- it should be more fedora extras-ish.

> 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.  I'm happy
to explain why things are the way they are in cpanflute2, and fix
those which are vestiges of old compatibilities which no longer matter
in the "modern" era.  We're all working for the same goal -- more
quality packages for everyone to enjoy :)


Chip Turner                   chip turner gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]