Thoughts...

[Ralf Corsepius]

On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
> "Chris Weyl" <cweyl at 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