[packagers] SPEC files for several catalyst (perl) related packages.

[Dag Wieers]

On Mon, 7 Jan 2008, Alessandro Forghieri wrote:

> Greetings & happy New Year
>
> Dag Wieers wrote:
> > [...]
> > It certainly is an option to override that build requirement, although I
> > don't know if it is possible somehow to only override that single build
> > requirement. Not any of the others. (Possibly modifying the Makefile.PL)
> >
> > I welcome such a solution.
>
> It can be done by removing the require line from either the spec or
> Makefile.PL. BTW, Test::Builder is not even used in the entire
> packageb(test suite included). Haven't tried make test though.

I will check now.


> >> A newer Test::Simple would conflict
> >> because of a man page - as does Tie::Refhash. Which is annoying to no end: wouldn't it be
> >> possible to change the man install basedir to /usr/local/man? That would make the package overlay
> >> with coreperl clean and painless.
> >
> > That is not an option, primarily because the system will still favor the
> > location of the perl package over the vendor and site installations. That
> > is something that Red Hat does on purpose to make sure people do not run
> > into problems because of CPAN installed modules (that also ship with Red
> > Hat).
>
> Mmmmhhh.... how so? unless I misunderstand what you're saying (a
> possibility), this is what I see: on my dev machine (I haven't messed
> with the core config files):
>
> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi;/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi;/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi;
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi;/usr/lib/perl5/site_perl/5.8.8;/usr/lib/perl5/site_perl/5.8.7;/usr/lib/perl5/site_perl/5.8.6;/usr/lib/perl5/site_perl/5.8.5;
> /usr/lib/perl5/site_perl;/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi;/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi;
> /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi;
> /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi;/usr/lib/perl5/vendor_perl/5.8.8;/usr/lib/perl5/vendor_perl/5.8.7;/usr/lib/perl5/vendor_perl/5.8.6;
> /usr/lib/perl5/vendor_perl/5.8.5;/usr/lib/perl5/vendor_perl;/usr/lib/perl5/5.8.8/i386-linux-thread-multi;/usr/lib/perl5/5.8.8;.
>
> So search path (shorn of versions and arch cruft) is, or appears to be,
> site_perl THEN vendor_perl THEN perl which would make overlaying
> packages kosher, unless I am missing something.

Ok, then they reversed their original stance on this and it is technical
possible to add them. Then we still need to think if we want to do this
(replace modules that are also shipped as part of the perl package).

I know some people need it, and I am certain that other people do not want
it. (Doing this would completely work around the protectbase or priority
plugins in yum so people would not expect to replace perl modules like
this)

However, I am willing to eg. release these as test packages are something
similar. A seperate repository might do as well ?


> > Besides there are other situations where one application or module needs a
> > newer version of some module, but another application or module cannot
> > work with this newer version. We cannot solve all problems and we do not
> > plan to either :-/
>
> That is true...but, shouldn't that be revealed at build?

How can it be revealed at build ? Only if you know in advance that newer
versions are not ABI compatible and have been marked like that in the SPEC
file.

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]