Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
1) What exactly do we gain with such splitting?
2) How did such a disruptive change got through Red-Eng as I haven't seen it announced as a milestone for F7 ? http://fedoraproject.org/wiki/CategoryFedora7Features
3) Again how does this only gets committed this last weekend (after the 4th test release)?
4) How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)?
Thanks in advance for your time, jpo (a very concerned user/packager that sees lot of his scripts broken because of missing perl core modules and doesn't want to review all his specfiles in order to add perl core modules to the build requirements list)
[1] - affects more than 650 packages
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size - Smaller buildsys size - Introduces real perl-module build-deps instead of a dependency on a "lumped-together" meta-rpm (=> improved long term stability of perl module packages) - The option to upgrade/replace "core perl modules".
- How did such a disruptive change got through Red-Eng as I haven't seen it announced as a milestone for F7 ? http://fedoraproject.org/wiki/CategoryFedora7Features
rel-eng would have to answer.
- Again how does this only gets committed this last weekend
(after the 4th test release)?
The split had been pending and discussed here for many weeks, but progress on the perl package had been a snail. Some details had been controversial, some details were broken, but 90% of the delays had been caused by collaboration not working.
IMO, the currently split is only "half of the story" and far from being complete.
- How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)?
Which harm does this to the Fedora run-time? It's a "grandfathering" approach and it's actually not different from not performing an ordered mass rebuilt.
Thanks in advance for your time, jpo (a very concerned user/packager that sees lot of his scripts broken because of missing perl core modules and doesn't want to review all his specfiles in order to add perl core modules to the build requirements list)
It's much less effort than you expect.
1. In almost all cases you will see hard rebuild-breakdowns with obvious "easy-fixes". In 90% of all cases all that would be required is to add "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) "BuildRequires: perl(Test::More)".
2. Such issues could easily be approached by a perl-SWAT team, but ...
3. It's a grandfathering approach. There is no need to rebuild everything.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size
- Smaller buildsys size
- Introduces real perl-module build-deps instead of a dependency on a
"lumped-together" meta-rpm (=> improved long term stability of perl module packages)
- The option to upgrade/replace "core perl modules".
That pretty much covers it as far as I'm concerned.
- How did such a disruptive change got through Red-Eng as I haven't seen it announced as a milestone for F7 ? http://fedoraproject.org/wiki/CategoryFedora7Features
rel-eng would have to answer.
- Again how does this only gets committed this last weekend
(after the 4th test release)?
The split had been pending and discussed here for many weeks, but progress on the perl package had been a snail. Some details had been controversial, some details were broken, but 90% of the delays had been caused by collaboration not working.
A large part of the problem was that I was distracted with other Red Hat projects. Also, I'm still very new at the whole packaging business, and had to rely on Spot and others for the bulk of the actual work here. So, I take full responsibility/blame for both the changes taking so long, and for them being pushed through so late. My feeling was that it is better to move ahead with this, and suffer angry module owners, than to wait for yet another release for these improvements.
IMO, the currently split is only "half of the story" and far from being complete.
#1 on my list is to get rid of the 'perlmodcompat' mess early in the F8 cycle. If anyone knows of a situation where the modcompat stuff actually useful at this point, let me know.
- How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)?
Which harm does this to the Fedora run-time? It's a "grandfathering" approach and it's actually not different from not performing an ordered mass rebuilt.
SRPMs can be rebuilt - the BuildRequires will be wrong, and the module authors will understandably be very annoyed with me, and will probably yell at me. I can take it.
- In almost all cases you will see hard rebuild-breakdowns with obvious
"easy-fixes". In 90% of all cases all that would be required is to add "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) "BuildRequires: perl(Test::More)".
Such issues could easily be approached by a perl-SWAT team, but ...
It's a grandfathering approach. There is no need to rebuild
everything.
^ What he said.
-RN
Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size
Does this justify breaking what people come to expect in a perl runtime environment, i.e., that every perl core module is available?
Isn't people loosing perspective by just looking at the packaging side of the question? This kind of change breaks end user code as the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed by default.
- Smaller buildsys size
Hardly worth the effort as almost every perl package will require ExtUtils::MakeMaker and one or more of the Test modules.
- Introduces real perl-module build-deps instead of a dependency on a
"lumped-together" meta-rpm (=> improved long term stability of perl module packages)
It will introduce maintenance problems in the long run as you continue to split core perl modules and also fail to follow the way upstream ships dual life perl modules (just look as ExtUtils::MakeMaker has been splitted in severeal sub-modules in recent years.
Also perl 5.10 is around the corner and will "offer" you plenty more modules to be splitted (just think Module::Build and all its dependencies).
- The option to upgrade/replace "core perl modules".
Can you give a concrete example of this?
That pretty much covers it as far as I'm concerned.
As it stands this change completely broke what I come to expect in every platform I have to work with perl (installing and support several perl apps). As this change is to disruptive to me I will most likely start phasing out Fedora as my main linux platform (and losing interest in continuing supporting the Perl packages I maintain).
This change also pollutes the perl specfiles with additional BR (perl core modules) and goes against what we have been doing for the last 3+ years (at least since Fedora.US).
- How did such a disruptive change got through Red-Eng as I haven't seen it announced as a milestone for F7 ? http://fedoraproject.org/wiki/CategoryFedora7Features
rel-eng would have to answer.
- Again how does this only gets committed this last weekend
(after the 4th test release)?
The split had been pending and discussed here for many weeks, but progress on the perl package had been a snail. Some details had been controversial, some details were broken, but 90% of the delays had been caused by collaboration not working.
A large part of the problem was that I was distracted with other Red Hat projects. Also, I'm still very new at the whole packaging business, and had to rely on Spot and others for the bulk of the actual work here. So, I take full responsibility/blame for both the changes taking so long, and for them being pushed through so late. My feeling was that it is better to move ahead with this, and suffer angry module owners, than to wait for yet another release for these improvements.
IMO, the currently split is only "half of the story" and far from being complete.
#1 on my list is to get rid of the 'perlmodcompat' mess early in the F8 cycle. If anyone knows of a situation where the modcompat stuff actually useful at this point, let me know.
- How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)?
Which harm does this to the Fedora run-time? It's a "grandfathering" approach and it's actually not different from not performing an ordered mass rebuilt.
SRPMs can be rebuilt - the BuildRequires will be wrong, and the module authors will understandably be very annoyed with me, and will probably yell at me. I can take it.
- In almost all cases you will see hard rebuild-breakdowns with obvious
"easy-fixes". In 90% of all cases all that would be required is to add "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) "BuildRequires: perl(Test::More)".
I believe you are being a little optimistic here. While adding ExtUtils::MakeMaker is trivial, adding Test::More, Test::Simple, and Test::Builder* is not.
Such issues could easily be approached by a perl-SWAT team, but ...
It's a grandfathering approach. There is no need to rebuild
everything.
^ What he said.
-RN
jpo
On 5/13/07, Jose Pedro Oliveira jpo@di.uminho.pt wrote:
Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size
Does this justify breaking what people come to expect in a perl runtime environment, i.e., that every perl core module is available?
Isn't people loosing perspective by just looking at the packaging side of the question? This kind of change breaks end user code as the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed by default.
I raised this issue (and a number of the others you bring up) a while back; hopefully you'll get more traction with this than I did :(
I'm not entirely sure why we're so focused on substituting our judgement for the perl team's as to what constitutes a core module, aside from some perverse fixation on breaking things and making life more difficult for everyone that touches anything perl in Fedora. --especially this late in the F7 release cycle!
I mean, really, what _actual_ problem are we trying to solve with this split? What are we trying to fix here?
- Smaller buildsys size
Hardly worth the effort as almost every perl package will require ExtUtils::MakeMaker and one or more of the Test modules.
And the splitted modules are hardly huge by any measure. I doubt it's unreasonable to claim there's more overhead in the additional rpm transactions/depsolving needed to handle installing the additional packages needed to supply these core modules.
- Introduces real perl-module build-deps instead of a dependency on a
"lumped-together" meta-rpm (=> improved long term stability of perl module packages)
I don't think it's fair to call perl a "meta-rpm", for a variety of obvious reasons. And even if the core perl tarball is a "meta-tarball", then at least its metaness is owned by a core perl team tasked with its maintenance.
[...snip...]
This change also pollutes the perl specfiles with additional BR (perl core modules) and goes against what we have been doing for the last 3+ years (at least since Fedora.US).
This has been an issue in reviews lately. People are packaging perl modules, and then being told "go add BR's on these core modules, but not those". It's confusing -- personally I feel like this split has taken a relatively well understood, straightforward process and made it fairly muddy -- shades of the recent review process changes.
I asked it above, but it's worth reiterating: what _actual_problem_ are we fixing with this split? Is it worth it?
-Chris
On Sun, 2007-05-13 at 12:22 -0700, Chris Weyl wrote:
On 5/13/07, Jose Pedro Oliveira jpo@di.uminho.pt wrote:
Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size
Does this justify breaking what people come to expect in a perl runtime environment, i.e., that every perl core module is available?
Isn't people loosing perspective by just looking at the packaging side of the question? This kind of change breaks end user code as the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed by default.
I raised this issue (and a number of the others you bring up) a while back; hopefully you'll get more traction with this than I did :(
I'm not entirely sure why we're so focused on substituting our judgement for the perl team's as to what constitutes a core module, aside from some perverse fixation on breaking things and making life more difficult for everyone that touches anything perl in Fedora. --especially this late in the F7 release cycle!
I mean, really, what _actual_ problem are we trying to solve with this split? What are we trying to fix here?
- Smaller buildsys size
Hardly worth the effort as almost every perl package will require ExtUtils::MakeMaker and one or more of the Test modules.
And the splitted modules are hardly huge by any measure.
The vast majority of perl modules are small, so this is to be expected.
The real point of package splits is cutting out functionality and making implicit package deps visible.
IMO, e.g. having cut out "cpan" alone is worth it. It implies user wanting to corrupt their rpm-based perl-installation will manually have to install it.
Splitting out EU::MM and Test::* makes (perl-module) deps visible Fedora's packaging policy so far has ignored - I don't see this a disadvantage.
- Introduces real perl-module build-deps instead of a dependency on a
"lumped-together" meta-rpm (=> improved long term stability of perl module packages)
I don't think it's fair to call perl a "meta-rpm", for a variety of obvious reasons. And even if the core perl tarball is a "meta-tarball", then at least its metaness is owned by a core perl team tasked with its maintenance.
Of cause I do not agree with you. To me the perl rpm has a "take everything/meta-rpm", lumping together many unrelated subpackages. I.e. a defect in packaging policy.
I take the fact "upstream lumps them together", * as a symptom of the clash between perl-upstream's and rpm's working principles (cpan vs. rpm). * as an indication of a clash between Fedora's principle to separate "run-time" from "devel" and perl upstream's principles.
This change also pollutes the perl specfiles with additional BR (perl core modules) and goes against what we have been doing for the last 3+ years (at least since Fedora.US).
This has been an issue in reviews lately. People are packaging perl modules, and then being told "go add BR's on these core modules, but not those". It's confusing -- personally I feel like this split has taken a relatively well understood, straightforward process and made it fairly muddy -- shades of the recent review process changes.
I asked it above, but it's worth reiterating: what _actual_problem_ are we fixing with this split?
Answered before.
Is it worth it?
Yes. It installing unused packages.
Ralf
On Sun, 2007-05-13 at 18:40 +0100, Jose Pedro Oliveira wrote:
Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
Hi,
As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through.
Questions:
Disclaimer: All answer are my personal view and opinion.
- What exactly do we gain with such splitting?
- Smaller install size
Does this justify breaking what people come to expect in a perl runtime environment, i.e., that every perl core module is available?
Yes. Sometimes it's time to break with old habits.
Isn't people loosing perspective by just looking at the packaging side of the question? This kind of change breaks end user code as the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed by default.
Where is the problem?
perl had been sloppily packaged in former Fedora releases, now things are being cleaned up.
- Smaller buildsys size
Hardly worth the effort as almost every perl package will require ExtUtils::MakeMaker and one or more of the Test modules.
Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or Test:: modules? Perl devs will, normal users won't except when other package will pull them in.
- Introduces real perl-module build-deps instead of a dependency on a
"lumped-together" meta-rpm (=> improved long term stability of perl module packages)
It will introduce maintenance problems in the long run as you continue to split core perl modules and also fail to follow the way upstream ships dual life perl modules (just look as ExtUtils::MakeMaker has been splitted in severeal sub-modules in recent years.
I don't see this as a problem. The rpms a perl module might be located in might change, but this should not affect a perl's module's dep on other modules. If they do, then perl has broken compatibility and we would be facing similar issues elsewhere.
Also perl 5.10 is around the corner and will "offer" you plenty more modules to be splitted (just think Module::Build and all its dependencies).
Yes. Module::Build and friends are on my radar. They are amongst the reasons for why I said "this split is far from being complete".
- The option to upgrade/replace "core perl modules".
Can you give a concrete example of this?
Check this list's archive. There repeatedly have been such requests.
Before the split, it was technically impossible to replace core perl modules, now we at least have the option to do so for those modules which have been split out.
- How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)?
Which harm does this to the Fedora run-time? It's a "grandfathering" approach and it's actually not different from not performing an ordered mass rebuilt.
SRPMs can be rebuilt -
That's an urban legend. All rpms in Fedora have been built against a set of packages that had been valid (and were reported to work) at one point in time. Even the mass-rebuilds in previous releases didn't actually change much about this, because they were _unsorted_ rebuilds.
the BuildRequires will be wrong, and the module
authors will understandably be very annoyed with me, and will probably yell at me.
I have no idea what you are referring to.
In case a user complains about an srpm you maintain not being rebuildable, you (the rpm-maintainer) can choose to fix it (essentially what "grandfathering" means - Fix upon request or need) or ignore this complaint.
In case an rpm's maintainer complains when he rebuilds a package he had not touched for ages. Shall he update his spec, like he would have been forced to do during a mass rebuild.
In case a perl-module author complains, ... I don't see how this is of any importance here.
- In almost all cases you will see hard rebuild-breakdowns with obvious
"easy-fixes". In 90% of all cases all that would be required is to add "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) "BuildRequires: perl(Test::More)".
I believe you are being a little optimistic here. While adding ExtUtils::MakeMaker is trivial, adding Test::More, Test::Simple, and Test::Builder* is not.
Then let me put it this way: I haven't encountered any case where fixing had not been possible (and actually can imagine any situation where this would not be possible).
In 90% of those cases I've adjusted it, it was adding "BuildRequires: perl(ExtUtils::MakeMaker)" (because most perl dists use EU:MM) and adding "perl(Test::More)" (for those case shipping testcases, almost all of EU::MM based dists).
- Such issues could easily be approached by a perl-SWAT team, but ...
I find it remarkable that none of you commented on this.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
[...]
the BuildRequires will be wrong, and the module
authors will understandably be very annoyed with me, and will probably yell at me.
I have no idea what you are referring to.
I think the threading got broken here. This was me speaking, and I meant to say 'package owners' instead of 'module authors'.
In case a user complains about an srpm you maintain not being rebuildable, you (the rpm-maintainer) can choose to fix it (essentially what "grandfathering" means - Fix upon request or need) or ignore this complaint.
In case an rpm's maintainer complains when he rebuilds a package he had not touched for ages. Shall he update his spec, like he would have been forced to do during a mass rebuild.
And he'll yell at me, probably. I'm ok with this.
- Such issues could easily be approached by a perl-SWAT team, but ...
I find it remarkable that none of you commented on this.
Are you volunteering to start one? I'll be happy to help as much as I can, time permitting. :-)
-RN
On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
- Such issues could easily be approached by a perl-SWAT team, but ...
I find it remarkable that none of you commented on this.
Are you volunteering to start one? I'll be happy to help as much as I can, time permitting. :-)
Again, a comment I can't deny to find remarkable.
I've been agitating to see "collaborative maintainership" to replace this unfortunate "one-package/one-owner" maintainership policy in Fedora ever since Fedora exists.
So far, there have always been circles in Fedora which strangled any such attempt.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
- Such issues could easily be approached by a perl-SWAT team, but ...
I find it remarkable that none of you commented on this.
Are you volunteering to start one? I'll be happy to help as much as I can, time permitting. :-)
Again, a comment I can't deny to find remarkable.
I've been agitating to see "collaborative maintainership" to replace this unfortunate "one-package/one-owner" maintainership policy in Fedora ever since Fedora exists.
So far, there have always been circles in Fedora which strangled any such attempt.
Well, what does collaborative maintainership mean to you, exactly? As you probably know, the vast majority of the recent changes to perl's spec file were contributed by spot and yourself - that's pretty collaborative. If you want commit access, one of the benefits of the merge is that you (or anyone else with a track record) could become a co-maintainer of any package in Fedora, not just the 'extras'. We wouldn't want just anyone to have commit access, obviously. Personally, I wouldn't want to get rid of the maintainer idea entirely, either - I think the personal responsibility and accountability implied by the maintainer role count for a lot.
-RN
On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
> 2. Such issues could easily be approached by a perl-SWAT team, but ...
I find it remarkable that none of you commented on this.
Are you volunteering to start one? I'll be happy to help as much as I can, time permitting. :-)
Again, a comment I can't deny to find remarkable.
I've been agitating to see "collaborative maintainership" to replace this unfortunate "one-package/one-owner" maintainership policy in Fedora ever since Fedora exists.
So far, there have always been circles in Fedora which strangled any such attempt.
Well, what does collaborative maintainership mean to you, exactly?
A team of equal (senior-, overseer-) maintainers simultaneously working collaboratively on something.
Not "a subordinate coding-monkey submits" something to a "devine maintainer", who applies a submitted change with several weeks of delay inbetween.
Of cause this requires some amount of trust and some amount of "self-distrust" and "self-reality check" ("I would like to ... but am not sure about it/this is not my domain ...").
Cf. how e.g. GCC works. Many people have privileges to access all files of the GCC source tree, but are supposed only to touch certain files or certain areas.
Wrt. perl rpms, the same principle could mean a "perl-packaging SWAT team" updating BR's of perl-module packages to reflect changes having been incorporated into the main perl.
Wrt. to the main perl package, this could have meant Spot, Ville or me to apply our patches ourselves and us having rebuilt the packages after you would have OK'ed the patches. It would have lifted some burden off your shoulders without many side-effects.
As you probably know, the vast majority of the recent changes to perl's spec file were contributed by spot and yourself - that's pretty collaborative.
May-be in comparison to how RH had processed RFEs so far - I can't judge.
From my POV, things actually did not proceed substantially different as
they would have done before the "Core/Extras" merger. I could have submitted patches as an RFE in bugzilla and wait for somebody @RH to react.
If you want commit access, one of the benefits of the merge is that you (or anyone else with a track record) could become a co-maintainer of any package in Fedora, not just the 'extras'. We wouldn't want just anyone to have commit access, obviously. Personally, I wouldn't want to get rid of the maintainer idea entirely, either - I think the personal responsibility and accountability implied by the maintainer role count for a lot.
It might surprise you but I don't disagree on this. There always needs to be some "authority with the final say", be it an individual or a committee or simply "majority". In GCC it's coordinated by applying different "patch policies" on different development branches and by "approving patches/patch reviews".
Wrt. FC this could mean: "Write after approval to any 'senior Fedora developer' on 'rawhide'", "Maintainer write-only on releases".
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote:
Well, what does collaborative maintainership mean to you, exactly?
A team of equal (senior-, overseer-) maintainers simultaneously working collaboratively on something.
Not "a subordinate coding-monkey submits" something to a "devine maintainer", who applies a submitted change with several weeks of delay inbetween.
Of cause this requires some amount of trust and some amount of "self-distrust" and "self-reality check" ("I would like to ... but am not sure about it/this is not my domain ...").
Cf. how e.g. GCC works. Many people have privileges to access all files of the GCC source tree, but are supposed only to touch certain files or certain areas.
Wrt. perl rpms, the same principle could mean a "perl-packaging SWAT team" updating BR's of perl-module packages to reflect changes having been incorporated into the main perl.
I'm not entirely sure how this would work in practice - the obvious way is to add a group of people as co-maintainers to all packages in the perl-* namespace. But I think we would want to ask existing maintainers before doing this to their packages, and I'm not sure how new perl-* packages would work, except by someone manually taking care of it (maybe if the package review process for new perl packages included this step. Would this be good enough? Do you have a better way?
Wrt. to the main perl package, this could have meant Spot, Ville or me to apply our patches ourselves and us having rebuilt the packages after you would have OK'ed the patches. It would have lifted some burden off your shoulders without many side-effects.
I'd be totally ok with this. Can I take this thread as a request by you to be added to the list of maintainers for perl? Spot had mentioned being added himself recently. Ville? Anyone else?
If you want commit access, one of the benefits of the merge is that you (or anyone else with a track record) could become a co-maintainer of any package in Fedora, not just the 'extras'. We wouldn't want just anyone to have commit access, obviously. Personally, I wouldn't want to get rid of the maintainer idea entirely, either - I think the personal responsibility and accountability implied by the maintainer role count for a lot.
It might surprise you but I don't disagree on this. There always needs to be some "authority with the final say", be it an individual or a committee or simply "majority". In GCC it's coordinated by applying different "patch policies" on different development branches and by "approving patches/patch reviews".
Wrt. FC this could mean: "Write after approval to any 'senior Fedora developer' on 'rawhide'", "Maintainer write-only on releases".
I think the release engineering and infrastructure teams are looking at these sorts of rules, but the tools don't exist yet, AFAIK.
-RN
On Monday, May 14, 2007 7:35 AM +0200 Ralf Corsepius rc040203@freenet.de wrote:
Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or Test:: modules? Perl devs will, normal users won't except when other package will pull them in.
Before the split, it was technically impossible to replace core perl modules, now we at least have the option to do so for those modules which have been split out.
In fact, EU:MM is exactly the module I needed to manually upgrade in the past, and had to install a local (unpackaged) version in my build environment to do so. I see this as a boon to dealing with broken outdated core packages that can now be updated in isolation without the extreme of updating the entire core.
This doesn't affect Fedora so much, with its rapid pace of development, but other, more conservative distros (eg. RHEL and CentOS) inherit Fedora packages and will benefit from this compartmentalization of change.
Kenneth Porter wrote:
On Monday, May 14, 2007 7:35 AM +0200 Ralf Corsepius rc040203@freenet.de wrote:
Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or Test:: modules? Perl devs will, normal users won't except when other package will pull them in.
Before the split, it was technically impossible to replace core perl modules, now we at least have the option to do so for those modules which have been split out.
In fact, EU:MM is exactly the module I needed to manually upgrade in the past, and had to install a local (unpackaged) version in my build environment to do so. I see this as a boon to dealing with broken outdated core packages that can now be updated in isolation without the extreme of updating the entire core.
This doesn't affect Fedora so much, with its rapid pace of development, but other, more conservative distros (eg. RHEL and CentOS) inherit Fedora packages and will benefit from this compartmentalization of change.
I wholeheartedly agree! I recently moved development of my application from RHEL to FC and was disappointed to have to package our own perl-Test-Simple because the Test::Builder in the main perl package was still broken. Everything else came as separate modules as needed.
So, it looks like now with FC7 (and esp. with FC8), even if Test::Builder still gives me problems, I'm only *upgrading* a package; not overwriting files that exist in another core package. Very nice...
Kelly
Kelly Corbin kcorbin@theiqgroup.com writes:
[...]
I wholeheartedly agree! I recently moved development of my application from RHEL to FC and was disappointed to have to package our own perl-Test-Simple because the Test::Builder in the main perl package was still broken. Everything else came as separate modules as needed.
Hi,
Broken how? Do you have a bugzilla?
Thanks,
-RN
I'm the sysadmin, not the developer so I don't have all the details at the moment (I'm waiting to hear back from him), but here's his quote to me: "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing an error to propagate outside of its code -- this is triggering the __DIE__ handler"
An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles.
I'll post as soon as I know more.
Kelly
Robin Norwood wrote:
Kelly Corbin kcorbin@theiqgroup.com writes:
[...]
I wholeheartedly agree! I recently moved development of my application from RHEL to FC and was disappointed to have to package our own perl-Test-Simple because the Test::Builder in the main perl package was still broken. Everything else came as separate modules as needed.
Hi,
Broken how? Do you have a bugzilla?
Thanks,
-RN
On 5/31/07, Kelly Corbin kcorbin@theiqgroup.com wrote:
I'm the sysadmin, not the developer so I don't have all the details at the moment (I'm waiting to hear back from him), but here's his quote to me: "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing an error to propagate outside of its code -- this is triggering the __DIE__ handler"
An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles.
I'll post as soon as I know more.
Hmm... What's the @INC directory scan order in our perl? I was under the impression it went site, vendor, core; that way you should be able to override something in core by installing it in either of the other two places (so perl finds it first).
...or am I missing something here? Disambiguation invited :)
-Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Weyl wrote:
On 5/31/07, Kelly Corbin kcorbin@theiqgroup.com wrote:
An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles.
Hmm... What's the @INC directory scan order in our perl?
Doesn't matter, Fedora uses a single directory structure for all manual pages (%_mandir), same goes for scripts (%_bindir).
So, even if those modules will be "vendor-installed", man pages & scripts will clobber files provided by "core" perl distro.
- -- Marius Feraru
On 5/31/07, Marius Feraru altblue@n0i.net wrote:
Chris Weyl wrote:
On 5/31/07, Kelly Corbin kcorbin@theiqgroup.com wrote:
An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles.
Hmm... What's the @INC directory scan order in our perl?
Doesn't matter, Fedora uses a single directory structure for all manual pages (%_mandir), same goes for scripts (%_bindir).
So, even if those modules will be "vendor-installed", man pages & scripts will clobber files provided by "core" perl distro.
Heh. Yes, those definitely would. I suppose it'd be easy enough to put the conflicting files in %doc, if they weren't needed as part of the update... Clearly not optimal, but an OK workaround for a local system.
-Chris
Here was the exact problem we ran into: "It throws "Can't call method 'isa' on an unblessed reference" inside of _is_object. Of course, Test::* is not supposed to let fatals leak out of its internal code. This was addressed in the version immediately following."
This bug must be fixed in 0.68 apparently (from the change log): 0.68 Tue Mar 13 17:27:26 PDT 2007 Bug fixes * If your code has a $SIG{__DIE__} handler in some cases functions like use_ok(), require_ok(), can_ok() and isa_ok() could trigger that handler. [rt.cpan.org 23509]
but a bug introduced 0.68 was fixed in 0.70 making it the optimal version.
Thanks!
Kelly
Kelly Corbin wrote:
I'm the sysadmin, not the developer so I don't have all the details at the moment (I'm waiting to hear back from him), but here's his quote to me: "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing an error to propagate outside of its code -- this is triggering the __DIE__ handler"
An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles.
I'll post as soon as I know more.
Kelly
Robin Norwood wrote:
Kelly Corbin kcorbin@theiqgroup.com writes:
[...]
I wholeheartedly agree! I recently moved development of my application from RHEL to FC and was disappointed to have to package our own perl-Test-Simple because the Test::Builder in the main perl package was still broken. Everything else came as separate modules as needed.
Hi,
Broken how? Do you have a bugzilla?
Thanks,
-RN
perl-devel@lists.fedoraproject.org