On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
"Chris Weyl" <cweyl(a)alumni.drew.edu> writes:
> Hey all --
>
> What with all the recent turmoil surrounding the Infamous Perl Split
> of naught-seven, I thought I'd take a few minutes and put down some of
> the areas in which I feel might need a little work. I don't intend
> for this note to spark a fire, or to be taken as anything but healthy,
> constructive criticism, but a solid discussion of these issues should
> provide for a stronger perl SIG going forward.
>
> What was the old Klingon adage? That which does not kill us makes us
> write more one-liners? :)
Chris,
Thanks for the ideas - responding inline.
> * buildrequres for perl modules.
>
> Until just recently, it was considered poor form to include core perl
> modules as buildrequires; now for a few of them we have to. Do we
> want to start including all core modules as BR's, or just the ones
> that have been split off? Regardless, we should document this (say
> under PackagingDrafts/Perl).
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 first need to decide exactly how far this split is going,
and
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.
Now, I can only urge you to revert your recent changes for rawhide (F8)
ASAP.
> * 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 as
> 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
inapplicable ...
> As we package more and more of CPAN, this is definitely an area
we
> should examine.
>
> This leads nicely into...
>
> * infrastructure.
>
> It just struck me that we have but a fraction of the "good" CPAN
> modules in Fedora, and as I push towards packaging more of Catalyst
> etc that number is going to rise. Fortunately, CPAN itself makes
> keeping track of these packages (and updates, etc) much easier -- and
> I have a couple scripts written to, e.g., compare the version in devel
> and the version in CPAN, etc. If we put a little effort into it,
> there's no reason we couldn't create a framework to regularly check
> packaged versions vs CPAN versions and post the results somewhere.
> --say in a Fedora-hosted project. (
perl.fedoraproject.org anyone?
> <grin>) Such an approach would benefit us all.
>
> A cpanspec-like tool to update specs, check br's, run a build and
> rpmlint it to assist with updates would also make life much easier.
Yeah, this has been one of my back-burner ideas for awhile now, too. I
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.
> * 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 have a
> 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
"filesystem" packages).
> * 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.
Changes, I had invested quite some considerable time in, because I had
thought you were aiming at getting them into FC7 - Apparently, I was
wrong.
- 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'
meta-goodness.
The split should be focused on separating "*devel" from
"runtime".
That was the motivation to split out "MakeMaker", CPAN, and Test::
modules (*devel packages).
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".
Ralf