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