On 3/5/07, Paul Howarth <paul@xxxxxxxxxxxx> wrote:
Warren Togami wrote:
> Ralf Corsepius wrote:
>>
>> As this thing doesn't seem to be baked yet[1], and as I don't want to
>> see FE-6 and FE-5 being locked out from updates, for now, I will ignore
>> this issue on rawhide, i.e. you will likely see broken EVRs between
>> rawhide and older FE, on my perl-modules, soon.
>
> Why broken EVR's?
Most perl module packages can use a common spec file across all
branches, except this is now broken in devel since perl-devel is needed
to build even noarch perl-based packages. So Ralf isn't updating perl
modules in devel until this is resolved, with the result that updated
packages in branches for older releases have higher EVRs than the
equivalent packages in devel. I'm doing likewise for the moment.
As am I.
So, it seems to me that splitting the .h files off into a perl-devel
package has introduced a number of issues that could be interpreted as
being anywhere in a range of "surprise!" to bug.
* ExtUtils::MakeMaker (at the least) depends on config.h, in -devel,
but is in core w/o a dep.
* End-users, not just developers/packagers, will be surprised by
ExtUtils::MakeMaker's being present but broken. (e.g. someone trying
to install extra modules from CPAN.)
* This is a departure from long standing practice in packaging
perl/perl-packages.
* A new buildreq will have to be added to every perl module (~530 in extras)
* Every perl-based package will require an examination to ensure that
they will not require perl-devel at run time. (I'd imagine most of
the ExtUtils packages would, but...)
* -devel contains /usr/lib/perl5/%{version}/Encode/*.h, which breaks
the ability of a package to buildrequires against perl(Encode).
I'm all for the division of devel and runtime packages; but in this
case I think we're going too far. We've split off what, as near as I
can tell, is a goodly number of .h files that do not introduce any
additional package deps, breaking at least two core modules, for the
reason "the guidelines say so". --or at least I haven't been able to
discern a better one. But as even the guidelines admonish they are
the beginning, not the ending of packaging[1], can we not admit that
core perl is both a devel and a user package, even after splitting out
the .h's?
What's next after this? Will we need to go out and split every .h
file from every perl package out, breaking the clean, simple and
effective method of simply needing to br a perl(foo) symbol?
Unless there's something I'm missing here -- entirely possible -- I'd
ask that this change be reverted, -devel be subsumed again by core,
and the core perl package be additionally flagged to provide
perl-devel (so as to not break any packages already merged to
conform).
-Chris
[1] "This is a collection of some guidelines for writing Fedora
packages. These guidelines are considered to be good practices by
existing Fedora packagers and QA people. If you are new to Fedora, you
should try to stick as closely to these guidelines as possible. When
you have gained some experience working with Fedora packages, you will
know when to deviate from them."
--
Chris Weyl
Ex astris, scientia
