[suggest] Possible bug in packaging of perl-Devel-StackTrace
I'd like to report a possible bug in the packaging of perl-Devel-StackTrace It appears that a previous version of the package was posted with a filename: perl-Devel-StackTrace-1.1902-1rpm The problem is, rpm will not see the new verison: perl-Devel-StackTrace-1.21-1rpm as an upgrade to the previous versions (1902 comes way after 21, after all). This will cause anything that depends on the updated version, such as perl-Exception-Class, to choke. The work around is to manually uninstall and reinstall the package, but package managers (such as YUM) will still try to upgrade this package back to 1902, possibly breaking perl applications in production (like, Request Tracker for instance). Marc DeTrano ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] Perl module additions and updates
Hello all, I'll keep it short and sweet by just listing what is needed: perl-SQL-Translator perl-B-Hooks-EndOfScope perl-Test-Warn Thanks, -- David Steinbrunner ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] Re: suggest Digest, Vol 49, Issue 9
From: arnebjarn...@hotmail.com Subject: Re: [suggest] subversion 1.6.3 for EL4 To be honest, I do not like all these hacks with locally build replacements. Subversion is a bear this way: the new feature sets are not well-modularized, and if you want the software, it *cannot* be easily reverse-engineered to avoid the dependencies. If it can't be build using vendors packages and the distribution system - kick it out - or use another repository :-) But this is a common problem, with subversion, perl-modules, and many other components for which older Fedora and *especially* RHEL lack up-to-date dependencies. with hacks somebody will at sometime screw something up (according to the Laws of Murphy) :-D. And by the way: Why is subversion build on EL5 at RPMforge?? It allready a part of the RHEL5 distribution. Because that version is seriously out of date, and the features of subversion 1.6.x more than justify the upgrade, and if you have an NFS client that is RHEL 5 for an environment that has Fedora 11 or Gentoo or even Cygwin or locally compiled UNIX versions, when you use subversion 1.6 on a shared filesystem, it will update your locally checked out copy and make it unusable for older versions of subversion. I just wish I had more time to get it working at RPMforge quality SRPM's, because the published ones I've found all have a bug in x86_64 with being unable to run the 'svn help' command. ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] Re: Perl module additions and updates
David Steinbrunner wrote: Hello all, I'll keep it short and sweet by just listing what is needed: perl-SQL-Translator perl-B-Hooks-EndOfScope perl-Test-Warn Got another that needs an update: perl-Moose Thanks, -- David Steinbrunner ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
[suggest] request Time::ParseDate
Hello, Would you please provide a package for perl Time::ParseDate (http://search.cpan.org/~muir/Time-modules-2006.0814/lib/Time/ParseDate.pm) for CentOS 5? Thanks, --Amos ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] collectd dependancies
I had a quick look at the buildlog. Maybe we could split the package and
make a nummber of sub-packages with the plugins. eg a
collectd-plugin-xmms containing only:
%{_libdir}/collectd/xmms.la
%{_libdir}/collectd/xmms.so
And requiring collectd = %{version} obviously. Could you try that
approach and share your results?
Hi Christoph
I have looked into your suggestion above and I see the EPEL repo has a
spec file which does a similar thing, so it certainly looks do-able, it is
taking me a long time to fiddle with it to get it right, but I will shout
when I have a spec.
Question for the list though -- I see the obsoletes line indicates that
there was previously a collectd-apache and collectd-mysql
collectd-sensors. This approach was clearly canned at some stage... any
ideas on why? would such a split again be accepted?
I have done a straight rebuild of the source rpm on a dev server which
doesn't have xmms or desktop libraries available and the resultant rpm has
much fewer dependancies since the configure script excludes a bunch of
stuff automatically. Some further clean-ups of the contrib/ directory
suggested by Craig Orsinger (who replied off list) and it ends up
dramatically reducing the dependancies.
Regards
-ant
d1...@1m3r
d1...@1m3r
d1...@1m3r
___
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Request: Required Perl Packages for Bugzilla 3.4
On 19/07/09 17:40, Dag Wieers wrote: On Fri, 17 Jul 2009, Max Kanat-Alexander wrote: Bugzilla 3.4 will be coming out soon, and it uses the following Perl packages as requirements or optionally: Template-Toolkit 2.22 (not out yet, but will be soon). TheSchwartz Daemon-Generic Could we get packages for these in rpmforge? (Particularly the last two would be nice, because they have a lot of prereqs.) I just packaged them, however perl-TheSchwartz requires perl-Data-ObjectDriver, which requires perl-DBD-Oracle, which requires something we cannot deliver right now. Data::ObjectDriver doesn't require DBD::Oracle. That's just one of the optional back-ends for it. It shouldn't be a mandatory requirement. Dave... ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Possible bug in packaging of perl-Devel-StackTrace
On Thu, 16 Jul 2009, Marc DeTrano wrote: I'd like to report a possible bug in the packaging of perl-Devel-StackTrace It appears that a previous version of the package was posted with a filename: perl-Devel-StackTrace-1.1902-1rpm The problem is, rpm will not see the new verison: perl-Devel-StackTrace-1.21-1rpm as an upgrade to the previous versions (1902 comes way after 21, after all). This will cause anything that depends on the updated version, such as perl-Exception-Class, to choke. The work around is to manually uninstall and reinstall the package, but package managers (such as YUM) will still try to upgrade this package back to 1902, possibly breaking perl applications in production (like, Request Tracker for instance). Hi Marc, yes, this problem was identified and fixed. The origin lies upstream and the workround is to package 1.21 as 1.2100 (until a 2.x release is made). Christophe already fixed it on Thursday. Let me know if you still have problems and thanks for reporting problems ! -- -- dag wieers, d...@wieers.com, 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] Request: Required Perl Packages for Bugzilla 3.4
On Sun, 19 Jul 2009, Dave Cross wrote: On 19/07/09 17:40, Dag Wieers wrote: On Fri, 17 Jul 2009, Max Kanat-Alexander wrote: Bugzilla 3.4 will be coming out soon, and it uses the following Perl packages as requirements or optionally: Template-Toolkit 2.22 (not out yet, but will be soon). TheSchwartz Daemon-Generic Could we get packages for these in rpmforge? (Particularly the last two would be nice, because they have a lot of prereqs.) I just packaged them, however perl-TheSchwartz requires perl-Data-ObjectDriver, which requires perl-DBD-Oracle, which requires something we cannot deliver right now. Data::ObjectDriver doesn't require DBD::Oracle. That's just one of the optional back-ends for it. It shouldn't be a mandatory requirement. Right, but it is pulled in with the auto requirements :-/ Time to implement that filter-macro and maybe commit it upstream so it becomes a standard ? -- -- dag wieers, d...@wieers.com, 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
