Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=156113 Stepan Kasal <skasal@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|Patch | Summary|[PATCH] Perl is built with |Perl is built with |debugging support |debugging support --- Comment #8 from Stepan Kasal <skasal@xxxxxxxxxx> 2009-08-28 13:59:20 EDT --- (In reply to comment #7) > That wouldn't be too complex (create a tag; [...] This was also my first impression when I discovered this problem. Fortunately, I do not have the rights to create a tag; I had to apply for it. A discussion followed, I had to advocate that I really need the tag; as time passed, I began to see more consequences and decided that this change is not as easy as it seems to be. First, I want to have dependencies right. My own system is randomly updated rawhide: at random times, I do "yum update some-packages" and I suppose that the dependencies are there mo ensure that everything works. Currently, Fedora has debug perl and debug modules, i.e., all were compiled with -DDEBUGGING. We would like to get have production perl and production modules. But debug modules do not work with production perl. The dependencies should reflect this. So the current debug modules have to require something that will not be provided by the production perl. What could that be? I cannot invent anything better than perl(:MODULE_COMPAT_5.10.0) So our final production perl may not provide that; it will provide perl(:MODULE_COMPAT_5.10.1) instead. But at beginning of August, when I consideres this move, there was still no 5.10.1 release candidate available. Top be able to do this, I would have to start by creating a snapshot labeled 5.10.1rc0 or some such. (The following week the alpha was postponed. But I afraid they didn't mean it as an opprtunity to start something that might then cause anither slip.) This was the main reason why I decide to leave fixing this bug for early dist-f13. But there were also two supportive reasons: Reason 1: I wanted to do exactly what Chris said: > create a tag; loop, bump & build to the tag; merge back to dist-f12 But that building to the tag is actually bootstrapping; you have to respect the BuildRequires and Requires. In theory, that should be easy. But we are not a source distribution, you cannot just "make world", so this is something which is not tested yet, so something is bound to break. And, indeed, Tom spot Callaway witnessed from his work on packaging 5.10.0 that such a bootstrap is a real PITA. Reason 2: Moreover, this is not the only change bound to the version number increase. The other one was advertised here: http://article.gmane.org/gmane.linux.redhat.fedora.perl/9664 > [...] but it would be a lot of churn for the middle of a beta cycle. Another consequence of asking for the tag was that they adverted me from my idea to slip in during the beta period. The risks are not worth the gain. I hope this all explains why we will (almost surely) stay with debug perl for Fedora 12. This comment does not discuss whether the change should be done using a separate tag or not. But that's an implementation issue that can be discussed on the fedora-perl-devel-list. [the "patch" keyword is no longer relevant] -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
