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

[Dag Wieers]

On Mon, 31 Dec 2007, Alessandro Forghieri wrote:

> Great job.
>
> I checked the relevant DBIx/Class Makefile.PL,
> and the Test::Builder requirement is a build_require (and needed
> only for tests, at that.
>
> So letting it out of the spec would not impair run time functionality, and that is what I'd do,
> because DBIx::Class is an almost irreplaceable part of Catalyst (it is possible to
> use it with DBI::Class, but that is clearly the losing technology, which is less and
> less mentioned in docs, articles, lists and so on).

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.


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

At least, I think that is the rationale. Besides it would be confusing if
we did and I am not here to break people's systems. At least not knowingly
;-)

I understand your frustation and I personally am not in favor of
Red Hat's policy of shipping perl modules as part of the perl package. But
as long as they are doing that, we have some extra limitations to what we
can offer. And if it means we cannot offer a complete set of catalyst
packages and some people have to make custom modifications to their
package-set, then so be it. At least they now they did it and they can
document thise custom changes.

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

At least we have simplified the work by offering a bigger set of perl
packages for EL5. (EL4 and older are even harder to do btw)

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