perl-devel April 2006

perl-devel@lists.fedoraproject.org

7 participants
49 discussions

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 25 Apr '06

25 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 ------- Additional Comments From mattdm(a)mattdm.org 2006-04-25 12:41 EST ------- Well, I think we had been considering *this* to be tracking that request. :) But if it makes it more clear, we can fork this into a new bug.... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 25 Apr '06

25 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 ------- Additional Comments From altblue(a)n0i.net 2006-04-25 12:36 EST ------- Matthew, I _absolutely_ agree with Ville. After all, "site_perl" has nothing to do with /usr, /usr/local is the _right_ place. Repeating that Kenneth meant to bake RPM packages, this is what I wanted to emphasize in fact, at least for Kenneth and others that may not know about our oldies but goldies conventions regarding (perl|site|vendor)dirs, which is exactly what you and Ville said after all: sitedir must not include RPM managed files, the same way /usr/local works. ;-) So, what stands out after all this chatter is Ville's proposal to move out sitedir under /usr/local. Ville, have you already submitted a request for this? :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 25 Apr '06

25 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 ------- Additional Comments From mattdm(a)mattdm.org 2006-04-25 12:01 EST ------- Marius -- the issue of 3rd-party RPM packages is a red herring and I agree that that portion should be considered hard to fix. However, the suggestion in comment #5 is still relevant for local and CPAN-installed modules, and there's no reason not to address that just because the _other_ part you're concerned about is difficult. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 25 Apr '06

25 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 ------- Additional Comments From altblue(a)n0i.net 2006-04-25 11:47 EST ------- Matthew, the issue raised by Kenneth here it's NOT about "non-packaged" files/modules/etc, but exactly about "how to make addon packages that should override distro files". OK, Kenneth minimized it to the state of a very particular issue, but the generic problem still stands, and kludging this "vendor specific man page directory" (yes, he meant _vendor_) - e.g. using that "%{_mandir}/manp/" trick - won't make the world better. ;-/ For instance, I don't get it who come [non-overriding] "is fine for binaries". Even more, remember what will happen when (main) perl package is updated: your addon package will _still_ override the distro package, given the current @INC's state in Fedora's perl package. Should I also mention that you will not be able to install your package as long Fedora tends to obsolete every separated-core-module-package (iep, they existed long ago, in the era of Chip Turner IIRC), _without_ specifying a version (e.g.: Obsoletes: perl-CPAN <= 1.76_02). So, IMHO a WONTFIX/CANTFIX resolution for this issue would be an easy way out (for now). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 ------- Additional Comments From mattdm(a)mattdm.org 2006-04-24 22:15 EST ------- Marius -- exactly right. The point is to make _non-packaged_ Perl modules (those installed locally) go into /usr/local instead of smearing themselves all over /usr/lib/perl5/. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 142837] Need site-specific man page directory
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Need site-specific man page directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142837 bugzilla(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Keywords| |FutureFeature ------- Additional Comments From altblue(a)n0i.net 2006-04-24 22:01 EST ------- Matthew: never EVER touch my /usr/local with packages! That's the least GoodThing FHS "establishes" ;-) Back on track, no, not (only) perl. If we would stick to the "subject", placing those man pages into a "%{_mandir}/manp/" would be enough to leverage the files conflict. Yes, I know it's just (another) workaround (with its own pros/cons), but at least it will (quite) work with the default man.config. IAE, this is not "THE" (real) issue. (As always) many workarounds (filed as "bugs" on the same bugtracker we're currently watching) are being filed just because our packaging system doesn't support "this" or "that" feature (and the main reason why some of our fellow developers "fallback" to other packaging systems - like [dq]pkg). IAE - yes, again - as this is not a "generic" boutade (and we're not on mozilla's bugtracker), I'll stop here with an "Happy Easter" ;-) As memento, don't touch /usr/local, it's one of the GoodThings RedHat/Fedora's guidelines stick to. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

[Bug 189833] h2ph problem with gcc internal defines
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

1 0

[Bug 189833] h2ph problem with gcc internal defines
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

1 0

[Bug 189833] h2ph problem with gcc internal defines
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

1 0

[Bug 189833] h2ph problem with gcc internal defines
by Red Hat Bugzilla 24 Apr '06

24 Apr '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: h2ph problem with gcc internal defines https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189833 jvdias(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |MODIFIED CC| |jlieskov(a)redhat.com ------- Additional Comments From jvdias(a)redhat.com 2006-04-24 19:40 EST ------- I was under the mistaken impression that this bug did not affect RHEL-3 - but it does: $ perl -e 'require "sys/socket.ph";' Can't locate features.ph in @INC (did you run h2ph?) $ perl -v ... This is perl, v5.8.0 built for ppc-linux-thread-multi ... $ uname -a uname -a Linux pseries.test.redhat.com 2.4.21-37.0.1.EL #1 SMP Wed Jan 11 18:37:26 EST 2006 ppc64 ppc64 ppc64 GNU/Linux This bug was found during testing of errata 2006:294 by Jan Lieskovsky <jlieskov(a)redhat.com> , during an attempted run of RHTS test script 185240.t, which failed. This test succeeded on my test machine because I had run h2ph on many include files manually a long time ago, and they were not removed by rpm upgrade - I had forgotten about them. It seems that this never worked in 5.8.0-89.10, the RHEL-3-U4 perl, either, since this make command, used to generate the list of headers to convert, failed, and 5.8.0-89.10 does not contain features.ph either : --- # Generate *.ph files with a trick. Is this sick or what ? make all -f - <<EOF PKGS = glibc-devel gdbm-devel gpm-devel libgr-devel libjpeg-devel \ libpng-devel libtiff-devel ncurses-devel popt \ zlib-devel binutils libelf e2fsprogs-devel pam pwdb \ rpm-devel STDH = \$(filter %{_includedir}/include/%%, \$(shell rpm -q --queryformat '[%%{FILENAMES}\n]' \$(PKGS))) ... --- While maybe not "sick", it was definitely not "well", as the rpm listing failed owing to the nonexistence of 'libgr-devel" (or "libelf") , so none of the headers intended to be shipped by the rpm listing were shipped. This is now fixed with perl-5.8.0-93.EL3, which ships all the headers in : gcc glibc-headers glibc-kernheaders binutils elfutils-devel \ gdbm-devel gpm-devel libjpeg-devel \ libpng-devel libtiff-devel ncurses-devel popt \ zlib-devel e2fsprogs-devel pam-devel \ rpm-devel | egrep '\.h$' Now the socket.ph requires succeeds, though with some warnings: $ perl -e 'require "sys/socket.ph";' Scalar found where operator expected at (eval 147) line 1, near "'int' $__val" (Missing operator before $__val?) String found where operator expected at (eval 394) line 1, near "&__const 'struct sockaddr'" (Missing operator before 'struct sockaddr'?) $ echo $? 0 The same warnings are generated when I convert the RHEL-3 headers with the latest upstream perl-5.8.8 version - it is an upstream h2ph problem, that I will fix in FC-{6,5,4} and later in RHEL-{3,4} in due course, but which is not critical for RHEL-3 - the requires and all tests now succeed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel April 2006