Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside)

Thorsten Leemhuis fedora at leemhuis.info
Thu Feb 12 18:39:50 UTC 2009


On 08.02.2009 13:51, Thorsten Leemhuis wrote:
> I prepared the next testing -> stable move for EPEL4 and EPEL5. I plan 
> to actually do the move on 20090212 at around 06:00 UTC.

Did the move earlier today. There were a lot of warnings like:

----
>   python-ruledispatch
>       python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm -> ppc
> WARNING: /srv/rpmbuild/epel/tree/epel/5/ppc/python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm already exists, ignoring new one
----

Here is the full list:

epel4:      obby-0.4.4-2.el4.src.rpm
epel4:      net6-1.3.5-1.el4.src.rpm
epel4:      perl-Filesys-Df-0.92-3.el4.src.rpm
epel4:      libmp4v2-1.5.0.1-6.el4.src.rpm
epel4:      perl-Test-Pod-Coverage-1.08-1.el4.src.rpm
epel4:      erlang-R11B-2.3.el4.src.rpm
epel4:      perl-String-CRC32-1.4-1.el4.src.rpm
epel4:      perl-Math-FFT-1.28-1.el4.src.rpm
epel4:      perl-XML-Filter-BufferText-1.01-4.el4.src.rpm
epel5:      python-ruledispatch-0.5a0-0.8.svnr2306.el5.src.rpm
epel5:      perl-Heap-0.80-1.el5.src.rpm
epel5:      perl-XML-Filter-BufferText-1.01-2.el5.src.rpm
epel5:      mingw32-w32api-3.12-8.el5.src.rpm
epel5:      python-dns-1.6.0-2.el5.src.rpm
epel5:      perl-Class-Inspector-1.17-1.el5.src.rpm
epel5:      python-configobj-4.4.0-2.el5.src.rpm
epel5:      perl-Test-Perl-Critic-1.01-1.el5.src.rpm
epel5:      python-libgmail-docs-0.3-6.el5.src.rpm
epel5:      dtc-1.1.0-1.el5.src.rpm
epel5:      net6-1.3.5-1.el5.src.rpm
epel5:      R-car-1.2-2.el5.src.rpm
epel5:      perl-Math-FFT-1.28-1.el5.src.rpm
epel5:      docbook2X-0.8.8-1.el5.src.rpm
epel5:      python-libgmail-0.1.8-2.el5.src.rpm
epel5:      perl-Algorithm-Annotate-0.10-6.el5.src.rpm
epel5:      python-turboflot-0.1.0-1.el5.src.rpm
epel5:      unbound-1.0.2-5.el5.src.rpm

Does anybody mind if I delete those from testing? Or do we want to force 
rebuild on those to make sure we know which packages users have 
installed? And does anyone volunteer to tell packagers why doing 
something that leads to above problems is bad?

CU
knurd




More information about the epel-devel-list mailing list