Re: [suggest] package for Net::MAC perl module

2008-09-18 Thread Peter Willis
While we're talking about the retarded Red Hat perl rpm, is anyone aware 
that perl 5.8 as shipped with RHEL has an unpatched bug which can cause 
an exponential slowdown when using overloading?

(This might have been adressed here already, and if so please ignore me :-X)

This blog post contains the details: 
http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/


I incorporated the patches from a core perl dev 
http://use.perl.org/~nicholas/journal/37274 which through some simple 
testing seems to fix the slowdowns while allowing one to retain all the 
Red Hat perl patches.  This is not the fedora patch which still has the 
potential for slowdowns.


As far as @INC is concerned, we patch our RHEL4 perl to use site_perl 
before vendor_perl (RHEL5 already does it this way). I've also started 
building my perl modules with /usr/local prefix for mandir, datadir, etc 
to avoid any conflicting files in the base perl package.


Dag Wieers wrote:

On Wed, 17 Sep 2008, Dave Cross wrote:


Dag Wieers wrote:


That is why I think we need to somehow make Red Hat understand that
they should not add CPAN distributions to the perl package.


It's not Red Hat that does this. The standard Perl distribution contains
modules that are also distributed independently from CPAN. They are
known as dual-life modules.


Right. But the fact that they are part of the perl RPM and not 
packaged as seperate RPMs makes it hard to replace them. Nothing 
forces Red Hat to ship them with the perl RPM.


In the past I thought it was because Red Hat did not want those 
modules to be replaced (given they have to support the system) and the 
default module path ctually confirmed that.


But since RHEL5 they allow to replace modules from site_perl because 
they changed the order, so there goes the bit of reverse psychology :) 
So I would have expected them to package them seperately so that at 
least it is more obvious from the package database that a certain RPM 
was in fact replaced.






perl58-slow-overloading.patch.gz
Description: application/gzip
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-18 Thread Peter Willis
Well how about that! Released yesterday... Well nevermind my patch then. 
(We could have used that 3 weeks ago when our biggest perl product 
launched, but it's good that they're finally getting to the fix)


Niels de Vos wrote:

Hi Ralph,

you probably meant: http://rhn.redhat.com/errata/RHBA-2008-0876.html

Cu,
Niels

On Thu, Sep 18, 2008 at 5:42 PM, Ralph Angenendt
[EMAIL PROTECTED]  wrote:
   

Peter Willis wrote:
 

While we're talking about the retarded Red Hat perl rpm, is anyone aware
that perl 5.8 as shipped with RHEL has an unpatched bug which can cause
an exponential slowdown when using overloading?
(This might have been adressed here already, and if so please ignore me :-X)
   

Especially as a patch has been released:

I think it'shttp://rhn.redhat.com/errata/RHBA-2008-0883.html, but
that is down at the moment.

Cheers,

Ralph

___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


 

___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest
   


___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dominik Gehl
Of course. I have a tool to generate the SPEC file so you don't have  
to spend the time creating one. I just need a list of the perl CPAN  
distribution to generate and build one.


How about DBIx::Class ? I see that the directory exists (http://dag.wieers.com/rpm/packages/perl-DBIx-Class/ 
) but doesn't currently contain any RPMs ...


Let me know if I can be of any help to generate/test the necessary  
SPEC files.


Thanks a lot,
Dominik

___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dag Wieers

On Wed, 17 Sep 2008, Dominik Gehl wrote:

Of course. I have a tool to generate the SPEC file so you don't have to 
spend the time creating one. I just need a list of the perl CPAN 
distribution to generate and build one.


How about DBIx::Class ? I see that the directory exists 
(http://dag.wieers.com/rpm/packages/perl-DBIx-Class/) but doesn't currently 
contain any RPMs ...


Feel free to test it yourself :)
With the new mirror-structure the buildlogs are not made available, we 
need to look at that and create standard buildlog format.



Let me know if I can be of any help to generate/test the necessary SPEC 
files.


Any help is welcome. Especially with SPEC files we have that did not 
produce RPM packages (like the perl-DBIx-Class).


--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dominik Gehl

Hi,

attached is a SPEC file for the latest version of DBIx::Class.

Dominik


perl-DBIx-Class.spec
Description: Binary data




On 17-Sep-08, at 12:15 PM, Dag Wieers wrote:


On Wed, 17 Sep 2008, Dominik Gehl wrote:

Of course. I have a tool to generate the SPEC file so you don't  
have to spend the time creating one. I just need a list of the  
perl CPAN distribution to generate and build one.


How about DBIx::Class ? I see that the directory exists (http://dag.wieers.com/rpm/packages/perl-DBIx-Class/ 
) but doesn't currently contain any RPMs ...


Feel free to test it yourself :)
With the new mirror-structure the buildlogs are not made available,  
we need to look at that and create standard buildlog format.



Let me know if I can be of any help to generate/test the necessary  
SPEC files.


Any help is welcome. Especially with SPEC files we have that did not  
produce RPM packages (like the perl-DBIx-Class).


--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]


___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dag Wieers

On Wed, 17 Sep 2008, Dominik Gehl wrote:


attached is a SPEC file for the latest version of DBIx::Class.


The problem was not the SPEC file, the problem is that it requires 
perl(Test::Builder) = 0.33.


Did you try to build it ? Because I am interested what satisfied this 
dependency for you. It normally is satisfied by perl-Test-Builder-Tester, 
but that one has problems of its own.


If you have CPAN on your system, then it is important to realise we cannot 
build against CPAN modules. All modules need to come from RPM.


PS The latest SPEC file is in subversion at:


http://svn.rpmforge.net/svn/trunk/rpms/perl-DBIx-Class/perl-DBIx-Class.spec

--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dominik Gehl


On 17-Sep-08, at 3:06 PM, Dag Wieers wrote:


On Wed, 17 Sep 2008, Dominik Gehl wrote:


attached is a SPEC file for the latest version of DBIx::Class.


The problem was not the SPEC file, the problem is that it requires  
perl(Test::Builder) = 0.33.


In fact, I found also an issue in the SPEC file ... if the two lines

Provides: perl(DBIx::Class::ClassResolver::PassThrough)
Provides: perl(DBIx::Class::Storage::TxnScopeGuard)

are not in the file, you can build the RPM but not install it since  
these are then missing dependencies.




Did you try to build it ?


Yes :-)

Because I am interested what satisfied this dependency for you. It  
normally is satisfied by perl-Test-Builder-Tester, but that one has  
problems of its own.


If you have CPAN on your system, then it is important to realise we  
cannot build against CPAN modules. All modules need to come from RPM.


I'll have a look and let you know

Dominik

___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dominik Gehl
Because I am interested what satisfied this dependency for you. It  
normally is satisfied by perl-Test-Builder-Tester, but that one has  
problems of its own.


If you have CPAN on your system, then it is important to realise we  
cannot build against CPAN modules. All modules need to come from RPM.


I'll have a look and let you know


Found it: I had upgraded Test::Builder using CPAN. On the other hand  
Test::Builder could be updated using perl-Test-Simple (which seems to  
build fine). The only issue is that its files conflict with those of  
perl-5.8.8-10.el5_2.3


Dominik

___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dag Wieers

On Wed, 17 Sep 2008, Dominik Gehl wrote:

 Because I am interested what satisfied this dependency for you. It 
 normally is satisfied by perl-Test-Builder-Tester, but that one has 
 problems of its own.
 
 If you have CPAN on your system, then it is important to realise we 
 cannot build against CPAN modules. All modules need to come from RPM.


I'll have a look and let you know


Found it: I had upgraded Test::Builder using CPAN. On the other hand 
Test::Builder could be updated using perl-Test-Simple (which seems to build 
fine). The only issue is that its files conflict with those of 
perl-5.8.8-10.el5_2.3


Right, which is a source of many problems. I would like to look at a 
simple solution that we can add to specific perl modules, so that on RHEL5 
they can be installed next to perl if needed.


Now, I would prefer not to do that by default. But optionally people could 
rebuild those packages with a specific flag and all will be well for them.


Again the reason why I do not want to ship perl packages that replaces 
modules shipped with perl is that depsolvers (think yum, apt) have no clue 
that they are pulling something that is already on the system and therefor 
users are not aware of them replacing base perl modules, which may break 
an existing perl application.


That is why I think we need to somehow make Red Hat understand that they 
should not add CPAN distributions to the perl package.


In the end we could make a seperate directory with those packages 
(tagged cpan ?) that are provided for those perl daredevils :)


Maybe that would satisfy Hugo as well ?

--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dominik Gehl

Hi,

according to 'perl -V', we have
  @INC:
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8
.

and the RHEL/CentOS RPMs perl RPM doesn't contain files in the  
site_perl directories. So, I believe, in order to install a module  
without getting conflicting files error messages, it should be  
sufficient to make sure that the new RPM puts its files into site_perl  
(and since site_perl appears earlier in @INC the new module should  
then be loaded).


What do you think ?

Dominik

On 17-Sep-08, at 3:55 PM, Dag Wieers wrote:


On Wed, 17 Sep 2008, Dominik Gehl wrote:

 Because I am interested what satisfied this dependency for you.  
It  normally is satisfied by perl-Test-Builder-Tester, but that  
one has  problems of its own.
  If you have CPAN on your system, then it is important to  
realise we  cannot build against CPAN modules. All modules need  
to come from RPM.

I'll have a look and let you know


Found it: I had upgraded Test::Builder using CPAN. On the other  
hand Test::Builder could be updated using perl-Test-Simple (which  
seems to build fine). The only issue is that its files conflict  
with those of perl-5.8.8-10.el5_2.3


Right, which is a source of many problems. I would like to look at a  
simple solution that we can add to specific perl modules, so that on  
RHEL5 they can be installed next to perl if needed.


Now, I would prefer not to do that by default. But optionally people  
could rebuild those packages with a specific flag and all will be  
well for them.


Again the reason why I do not want to ship perl packages that  
replaces modules shipped with perl is that depsolvers (think yum,  
apt) have no clue that they are pulling something that is already on  
the system and therefor users are not aware of them replacing base  
perl modules, which may break an existing perl application.


That is why I think we need to somehow make Red Hat understand that  
they should not add CPAN distributions to the perl package.


In the end we could make a seperate directory with those packages  
(tagged cpan ?) that are provided for those perl daredevils :)


Maybe that would satisfy Hugo as well ?

--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]


___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dag Wieers

On Wed, 17 Sep 2008, Dominik Gehl wrote:


On 17-Sep-08, at 3:55 PM, Dag Wieers wrote:


On Wed, 17 Sep 2008, Dominik Gehl wrote:

Because I am interested what satisfied this dependency for you. It  
normally is satisfied by perl-Test-Builder-Tester, but that one has 
 problems of its own.
 If you have CPAN on your system, then it is important to realise 
 we  cannot build against CPAN modules. All modules need to come 
 from RPM.

  I'll have a look and let you know
 
 Found it: I had upgraded Test::Builder using CPAN. On the other hand 
 Test::Builder could be updated using perl-Test-Simple (which seems to 
 build fine). The only issue is that its files conflict with those of 
 perl-5.8.8-10.el5_2.3


Right, which is a source of many problems. I would like to look at a simple 
solution that we can add to specific perl modules, so that on RHEL5 they 
can be installed next to perl if needed.


Now, I would prefer not to do that by default. But optionally people could 
rebuild those packages with a specific flag and all will be well for them.


Again the reason why I do not want to ship perl packages that replaces 
modules shipped with perl is that depsolvers (think yum, apt) have no clue 
that they are pulling something that is already on the system and therefor 
users are not aware of them replacing base perl modules, which may break an 
existing perl application.


That is why I think we need to somehow make Red Hat understand that they 
should not add CPAN distributions to the perl package.


In the end we could make a seperate directory with those packages (tagged 
cpan ?) that are provided for those perl daredevils :)


Maybe that would satisfy Hugo as well ?


and the RHEL/CentOS RPMs perl RPM doesn't contain files in the site_perl 
directories. So, I believe, in order to install a module without getting 
conflicting files error messages, it should be sufficient to make sure that 
the new RPM puts its files into site_perl (and since site_perl appears 
earlier in @INC the new module should then be loaded).


What do you think ?


That is correct, so technically it is possible. But as I outlined before, 
people might not know what is going on when they pull in eg. a 
newer perl-CGI and will not understand why something else suddenly is 
breaking.


apt or yum with the protectbase or priorities plugin will not consider 
the perl-CGI packages as replacing a base package and therefor will not 
protect your system from this update.


So while it is technically possible (at least on RHEL5), I think it is 
undesirable to provide this to normal users from the normal repository.


--
--   dag wieers,  [EMAIL PROTECTED],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest


Re: [suggest] package for Net::MAC perl module

2008-09-17 Thread Dave Cross
Dag Wieers wrote:

 That is why I think we need to somehow make Red Hat understand that
 they should not add CPAN distributions to the perl package.

It's not Red Hat that does this. The standard Perl distribution contains
modules that are also distributed independently from CPAN. They are
known as dual-life modules.

Dave...
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest