Ralf Corsepius <rc040203@xxxxxxxxxx> writes: > On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote: >> "Chris Weyl" <cweyl@xxxxxxxxxxxxxxx> 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 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. 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 (F8) > ASAP. 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 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 ... I'm not really sure what you mean here...what specific problems do you see? [...] >> 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. 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 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). 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 and cons. >> > * 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 had > thought you were aiming at getting them into FC7 - Apparently, I was > wrong. 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' >> 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). 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. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching
