[Bug 156113] Perl is built with debugging support

[bugzilla at redhat.com]

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 at redhat.com> 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 at redhat.com>  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.