On Sun, 2007-05-13 at 12:22 -0700, Chris Weyl wrote: > On 5/13/07, Jose Pedro Oliveira <jpo@xxxxxxxxxxxx> wrote: > > Robin Norwood wrote: > > > Ralf Corsepius <rc040203@xxxxxxxxxx> writes: > > > > > >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: > > >>> Hi, > > >>> > > >>> As I have been rather busy in the past months I haven't had the time > > >>> to follow the mailing lists and only this weekend did I realize that > > >>> the disruptive [1] change of splitting perl had been pushed through. > > >>> > > >>> Questions: > > >> Disclaimer: All answer are my personal view and opinion. > > >> > > >>> 1) What exactly do we gain with such splitting? > > >> - Smaller install size > > > > Does this justify breaking what people come to expect in a > > perl runtime environment, i.e., that every perl core module is > > available? > > > > Isn't people loosing perspective by just looking at the packaging > > side of the question? This kind of change breaks end user code as > > the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed > > by default. > > I raised this issue (and a number of the others you bring up) a while > back; hopefully you'll get more traction with this than I did :( > > I'm not entirely sure why we're so focused on substituting our > judgement for the perl team's as to what constitutes a core module, > aside from some perverse fixation on breaking things and making life > more difficult for everyone that touches anything perl in Fedora. > --especially this late in the F7 release cycle! > > I mean, really, what _actual_ problem are we trying to solve with this > split? What are we trying to fix here? > > > >> - Smaller buildsys size > > > > Hardly worth the effort as almost every perl package will require > > ExtUtils::MakeMaker and one or more of the Test modules. > > And the splitted modules are hardly huge by any measure. The vast majority of perl modules are small, so this is to be expected. The real point of package splits is cutting out functionality and making implicit package deps visible. IMO, e.g. having cut out "cpan" alone is worth it. It implies user wanting to corrupt their rpm-based perl-installation will manually have to install it. Splitting out EU::MM and Test::* makes (perl-module) deps visible Fedora's packaging policy so far has ignored - I don't see this a disadvantage. > > >> - Introduces real perl-module build-deps instead of a dependency on a > > >> "lumped-together" meta-rpm (=> improved long term stability of perl > > >> module packages) > > I don't think it's fair to call perl a "meta-rpm", for a variety of > obvious reasons. And even if the core perl tarball is a > "meta-tarball", then at least its metaness is owned by a core perl > team tasked with its maintenance. Of cause I do not agree with you. To me the perl rpm has a "take everything/meta-rpm", lumping together many unrelated subpackages. I.e. a defect in packaging policy. I take the fact "upstream lumps them together", * as a symptom of the clash between perl-upstream's and rpm's working principles (cpan vs. rpm). * as an indication of a clash between Fedora's principle to separate "run-time" from "devel" and perl upstream's principles. > > This change also pollutes the perl specfiles with additional BR > > (perl core modules) and goes against what we have been doing for > > the last 3+ years (at least since Fedora.US). > > This has been an issue in reviews lately. People are packaging perl > modules, and then being told "go add BR's on these core modules, but > not those". It's confusing -- personally I feel like this split has > taken a relatively well understood, straightforward process and made > it fairly muddy -- shades of the recent review process changes. > > I asked it above, but it's worth reiterating: what _actual_problem_ > are we fixing with this split? Answered before. > Is it worth it? Yes. It installing unused packages. Ralf
