Ralf Corsepius <rc040203(a)freenet.de> writes:
On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
> "Chris Weyl" <cweyl(a)alumni.drew.edu> writes:
> I don't know if it makes sense to include all the core modules as BR's -
It does, because this is the only way to guarantee long term stability.
IMO, the confusion you see know largely is only a side-effect of the
perl-module packaging having been "too lax" so far. If all perl-modules
packaging would have applied stricter rules, you'd be able to move
perl-core modules between packages, and nobody would have noticed.
"BR-ing core-modules in *.specs", in practice condenses to a handful of
modules, namely those explicitly required by a module's build
infrastructure. Anything else will be pulled in automatically.
I think we need to decide exactly what the goal is with splitting out
the core modules - some people think we should split them all out,
others want a smaller set. I'm not really sure which is best at the
moment...I think it requires more discussion.
> I think we first need to decide exactly how far this split is
> then it will be more clear which BR need to be explicitly stated.
... We would have had opportunities to gain clarity, if you had not
reverted the split.
This isn't actually true. The modules are still split out. The changes
were to make the perl-devel require the other split modules, and include
the split modules in the default install. You can still remove
perl-devel + co at install time or later, if you wish.
And yes, this is two steps forward, one step back. I wasn't really very
happy with it, but enough people were going to be negatively impacted by
this change that spot and I both decided it would be best to go this
way. I would rather have made a clean split instead of doing it this
way, but I have to accept that we didn't give enough warning to make
people comfortable with this change.
Now, I can only urge you to revert your recent changes for rawhide
I agree. I'll look at it Monday, unless one of the co-maintainers gets
to it first. :-)
> > * co-maintainership.
> > For the record, if there's something that needs to be done to any of
> > my perl packages, I don't have a problem with it. (E.g. a coordinated
> > effort to add the newly-missing br's to them, etc). I only ask that
> > the minimum change necessary be made, a note be sent to this list, and
> > a reasonable effort be made to contact me first. I rather like Ralf's
> > idea of a "SWAT team", but I don't think it needs to be phrased
> > such: as a SIG cooperating together to improve the state of Perl in
> > Fedora as a whole we can accomplish much.
> For now, at least, list list is low-traffic enough to support the
> SWAT-type activities...we just need to define how we interact with the
> package owners, and get their buy-in/permission/forgiveness.
Well, meanwhile, given how the merger changes Fedora's workflow, I am
not sure anymore if a "SWAT" team can work. Things which had been easy
before (and to some extend could have been scripted), now seem to become
I'm not really sure what you mean here...what specific problems do you
> Yeah, this has been one of my back-burner ideas for awhile now,
> don't think there's anything really magical or hard here we just need to
> get it on someone's front burner and get it done. I'll see about taking
> a stab at it in the next couple of weeks and see how far I get.
Steven Pritchard has/had a couple of nice scripts.
Yeah, I believe I've seen them on the wiki.
> > * perl packaging guidelines could use some love.
> > One of the things I've been becoming acutely aware of lately is that
> > there's a large body of customs and best practices in terms of
> > packaging perl modules that we've built up over the years. From
> > things like "prefer Build.PL over Makefile.PL" to simple things like
> > "It's 'GPL or Artistic', not the other way around", we
> > consensus on The Reasonable Way To Package Modules.
> > However, it's not written down anywhere :)
Is there a need to do so? I don't think so.
Build.PL or Makefile.PL should not matter at all (It matters that a
package builds) - Some CPAN authors prefer Build.PL, I hate it and
consider it to be "mal-designed junk".
We have other "semi-written rules" which are much more of importance
(e.g. perl modules must own all dirs not owned by the "perl" or
I think documented best practices are a good idea - if there's debate
between possible options, we can present both of them along with pros
> > * SIG communication and coordination.
> > If there's one thing that the recent perl split has exposed, it's that
> > there are some strong opinions about the proper way to do things, held
> > by many people -- myself included :) In an environment like this,
> > it's critical (IMHO) to lead up to major changes through a through and
> > open discussion on the list (and perhaps IRC). An attempt at reaching
> > a consensus should be given serious effort, and changes should be done
> > in a reasonable way (e.g. in the beginning of a development cycle).
> > Even if a consensus cannot be reached, a reasonable effort at it will
> > help everyone accept the outcome.
> > Very few of us here are paid to do this. We're here for a variety of
> > reasons, all of which are valid, and because of that it's even more
> > important for us to be engaged as a community, and to feel that we
> > have a stake (and say!) in it.
> I'll try to do better with this for F8
Glad to hear you say this - I am pretty disappointed about seeing the
split effectively having been reverted, last minute.
Again, they weren't reverted - though I take your point that including
them default is practically the same thing.
Changes, I had invested quite some considerable time in, because I
thought you were aiming at getting them into FC7 - Apparently, I was
I had planned to, but was convinced that the disruption to users and
developers would be too great. I probably should've brought you into
the discussion, considering the contributions you'd made. Sorry!
> - unfortunately perl stuff got
> pushed too far out in the cycle of things I pay attention to during F7's
> dev cycle.
> A couple of things specifically I'd like to look at early in F8 in
> addition to your list:
> o Finalize 'the split' - which packages do we still want to split from
> perl? All of them?? If we do split everything out that we can, we
> probably need some sort of 'perl-core/perl-devel/perl-everything'
The split should be focused on separating "*devel" from "runtime".
That was the motivation to split out "MakeMaker", CPAN, and Test::
modules (*devel packages).
That's my gut feeling about it - but some people seem to think it would
be worthwhile to split out everything. That approach would make it
easier to update 'core' module piecemeal if needed to fix bugs - but
leads to a lot of packages to have a 'core' perl distribution in
Fedora. So, I think more discussion is warrented.
> o Fix up the dependencies, (probably) remove the 'devel'
rpms from the
> buildroots, the and anaconda set of default RPMS.
> - And fix the dependencies on other perl-* packages.
> o Remove the %perlmodcompat stuff, unless someone has a good reason to
> keep it.
* Clean up rpm not to provide bogus libXXX.so's on perl's dynamically
loaded *.so. Probably all of them are "plain wrong".
Ok. I think we have a pretty good hit list going here. I'll put them
up on the wiki somewhere this weekend.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching