Hi,
We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place.
This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7.
What do you think?
For reference, these are the packages in question: perl-devel perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple
-RN
On Wed, 2007-05-16 at 11:32 -0400, Robin Norwood wrote:
Hi,
We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place.
This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7.
What do you think?
Wrong move.
This renders perl-devel into a meta-package and voids/avoids forcing users to use full BuildRequires.
I.e. this widely spoils and voids one fundamental aspect the split is aiming at.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-16 at 11:32 -0400, Robin Norwood wrote:
Hi,
We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place.
This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7.
What do you think?
Wrong move.
This renders perl-devel into a meta-package and voids/avoids forcing users to use full BuildRequires.
I.e. this widely spoils and voids one fundamental aspect the split is aiming at.
I agree, to a point - however, with all this happening so late in the cycle, many people were annoyed at how impactful the changes would be. It's even too late for release notes, so we couldn't hide behind the 'but it was in the release notes...you *did* read the release notes, right?' defense. This way we get to keep the split, and we can remove the packages from the default install early in the F8 dev cycle, giving us more time to warn/badger perl module owners.
-RN
On 5/16/07, Robin Norwood rnorwood@redhat.com wrote:
Hi,
We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place.
This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7.
What do you think?
This could at least stabilize things for F7 -- everything is present the way it was in fc6, but ready for a more measured approach for F8. If we're going forward with the split I think this is a good way to do it.
So how are we planning on doing this? A comps change or having core perl require it's subpackages? If it's just a comps change, how will this work with upgrades (via anaconda or, eg, a yum / apt upgrade)?
-Chris
On Thu, 2007-05-17 at 08:17 -0700, Chris Weyl wrote:
On 5/16/07, Robin Norwood rnorwood@redhat.com wrote:
Hi,
We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place.
This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7.
What do you think?
This could at least stabilize things for F7 -- everything is present the way it was in fc6,
Exactly: No progress.
Development-wise a step backwards.
Ralf
On 5/17/07, Ralf Corsepius rc040203@freenet.de wrote:
This could at least stabilize things for F7 -- everything is present the way it was in fc6,
Exactly: No progress.
Development-wise a step backwards.
At least this way we'd get a chance to take a breath, address concerns that a number of people have with this, and plan for F8 in a sensible way.
-Chris
On Thu, 2007-05-17 at 10:09 -0700, Chris Weyl wrote:
On 5/17/07, Ralf Corsepius rc040203@freenet.de wrote:
This could at least stabilize things for F7 -- everything is present the way it was in fc6,
Exactly: No progress.
Development-wise a step backwards.
At least this way we'd get a chance to take a breath, address concerns that a number of people have with this, and plan for F8 in a sensible way.
<Sigh/> Red Hat, you've had all of your chances in your hands, but you missed them - once again.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Thu, 2007-05-17 at 10:09 -0700, Chris Weyl wrote:
On 5/17/07, Ralf Corsepius rc040203@freenet.de wrote:
This could at least stabilize things for F7 -- everything is present the way it was in fc6,
Exactly: No progress.
Development-wise a step backwards.
At least this way we'd get a chance to take a breath, address concerns that a number of people have with this, and plan for F8 in a sensible way.
<Sigh/> Red Hat, you've had all of your chances in your hands, but you missed them - once again.
It's a compromise. It's not perfect, but it makes forward progress without annoying too many people. Like I said, we can work on fixing it better early in the F8 cycle this time, rather than so late in the F7 cycle.
And, don't say "Red Hat" - that's pointless, because there's no personal responsibility when you blame an entire company. If you want to point fingers, blame me, because it was my call.
-RN
perl-devel@lists.fedoraproject.org