Re: [suggest] package for Net::MAC perl module
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] packages for Net::Appliance::Session and Net::Appliance::Phrasebook
We already had Net::Appliance::Phrasebook, albeit not the latest version so I updated the package. Thanks a lot ! I had a look and found that the following modules could also be updated Text::SimpleTable (version 0.03 vs 0.05) Template (version 2.19 vs 2.20) Set::Object (version 1.22 vs 1.25) Regexp::Common (version 2.120 vs 2.122) Params::Validate (version 0.89 vs 0.91) Log::Log4perl (version 1.15 vs 1.18) Data::Visitor (version 0.15 vs 0.21) CGI::Session (version 4.20 vs 4.36) Would there be any interest in automatically generating a list of modules which can be updated ? Thanks, Dominik ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] packages for Net::Appliance::Session and Net::Appliance::Phrasebook
On Wed, 17 Sep 2008, Dominik Gehl wrote: We already had Net::Appliance::Phrasebook, albeit not the latest version so I updated the package. Thanks a lot ! I had a look and found that the following modules could also be updated Text::SimpleTable (version 0.03 vs 0.05) Template (version 2.19 vs 2.20) Set::Object (version 1.22 vs 1.25) Regexp::Common (version 2.120 vs 2.122) Params::Validate (version 0.89 vs 0.91) Log::Log4perl (version 1.15 vs 1.18) Data::Visitor (version 0.15 vs 0.21) CGI::Session (version 4.20 vs 4.36) Would there be any interest in automatically generating a list of modules which can be updated ? No, I can do that already. It is fixing them by hand manually and doing a test-build that could need some help. The scripts for creating the list and creating SPEC files is available from: http://svn.rpmforge.net/svn/trunk/tools/dar/dar-diff-perl.sh http://svn.rpmforge.net/svn/trunk/tools/dar/dar-list-perl.py http://svn.rpmforge.net/svn/trunk/tools/dar/dar-perl.py But some of them may require a DAR environment. -- -- 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
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
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
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
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
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
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
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
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
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
Re: [suggest] package for Net::MAC perl module
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. -- -- 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
So how about installing this limited number of perl modules into some 'new' directory (outside of @INC) and having a 'perl-rpmforge- activator' RPM which basically would just prepend this new directory to @INC ? This way it would be pretty easy to activate and de-active these modules, there would be no conflicting files etc. Dominik On 17-Sep-08, at 6:14 PM, 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. -- -- 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 ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest