On Sat, 2007-05-19 at 16:04 -0400, Robin Norwood wrote: > 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. You have effectively reverted the split. > The changes > were to make the perl-devel require the other split modules, and include > the split modules in the default install. Exactly this is the reversion - Forcing "module'ed" BR's and R's to gain long term packaging stability was one of the prime objectives. Now, you're allowing people to continue their sloppy (bad) habits. > >> > * 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? You aren't subscribed to maintainers@? Then you'd better be. > > 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! OSS development is based on "give and take" ... You will have to understand that such lonesome and lately communicated decisions drive external volunteers away. > >> - 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. There likely are more modules which would make sense to be split out, but a "split out everything" would be stupid. What I think the next steps should be 1. Revert your recent changes 2. Reconsider the *-lib split. 3. Reflect this split to perl-modules. .. n. Check for further split-out candidates. Ralf
