Broken upgrade path report for repositories EL4, EL4-updates, EPEL4, EPEL4-testing, EL5, EL5-updates, EPEL5, EPEL5-testing
Fedora AT FamilleCollet com: cups-pdf EPEL4 > EPEL5 (0:2.4.6-2.el4 > 0:2.4.6-1.el5)
Jochen AT herr-schmitt de: kyum EPEL4-testing > EPEL5-testing (0:0.7.5-9.el4.1 > 0:0.7.5-4.el5)
UNKNOWN OWNER (possibly Core package): device-mapper EL4 > EL5 (0:1.02.21-1.el4 > 0:1.02.20-1.el5)
dmraid EL4 > EL5 (0:1.0.0.rc14-6_RHEL4_U5 > 0:1.0.0.rc13-4.el5)
edac-utils EL4-updates > EL5 (0:0.9-7_el4 > 0:0.9-5.el5)
ethtool EL4 > EL5 (0:6-1 > 0:5-1.el5)
frysk EL4 > EL5 (0:0.0.1.2007.08.03-7.el4 > 0:0.0.1.2007.06.21.rh2-4.el5)
lvm2 EL4-updates > EL5 (0:2.02.27-2.el4_6.1 > 0:2.02.26-3.el5)
MySQL-python EL4 > EL5 (0:1.2.1_p2-1.el4.1 > 0:1.2.1-1)
openib EL4 > EL5-updates (0:1.2-7 > 0:1.2-6.el5_1.1)
sg3_utils EL4 > EL5 (0:1.22-3.1 > 0:1.20-2.1)
system-config-lvm EL4 > EL5 (0:1.0.23-1.0 > 0:1.0.22-1.0.el5)
wpa_supplicant EL4 > EL5 (1:0.4.9-1.1.el4 > 1:0.4.8-10.1.fc6)
a badger AT gmail com: python-docutils EPEL4 > EPEL5 (0:0.4-4.el4 > 0:0.4-3.el5)
bojan AT rexursive com: viewvc EPEL4 > EPEL5-testing (0:1.0.4-2.el4 > 0:1.0.4-1.el5)
denis AT poolshark org: plotutils EPEL4 > EPEL5-testing (0:2.5-5.el4 > 0:2.5-3.el5)
pstoedit EPEL4-testing > EPEL5-testing (0:3.45-2.el4 > 0:3.44-5.el5)
dennis AT ausil us: mercurial EPEL4 > EPEL5 (0:0.9.5-2.el4 > 0:0.9.3-1.el5)
foolish AT guezz net: nbtscan EPEL4 > EPEL5 (0:1.5.1-2.el4 > 0:1.5.1-1.el5)
ianburrell AT gmail com: jigdo EPEL4-testing > EPEL5-testing (0:0.7.3-4.el4 > 0:0.7.3-2.el5)
jamatos AT fc up pt: python-imaging EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
jeff AT ocjtech us: python-genshi EPEL4 > EPEL5 (0:0.4.4-2.el4 > 0:0.4.4-1.el5)
lmacken AT redhat com: obby EPEL4 > EPEL5 (0:0.4.4-2.el4 > 0:0.4.4-1.el5)
python-configobj EPEL4 > EPEL5 (0:4.4.0-2.el4 > 0:4.4.0-1.el5)
python-formencode EPEL4 > EPEL5 (0:0.7.1-2.el4 > 0:0.7.1-1.el5)
python-paste-script EPEL4-testing > EPEL5 (0:1.3.6-1.el4 > 0:1.1-1.el5)
mastahnke AT gmail com: cdpr EPEL4 > EPEL5 (0:2.2.1-3.el4 > 0:2.2.1-2.el5)
mfleming+rpm AT enlartenment com: python-GeoIP EPEL4 > EPEL5-testing (0:1.2.1-7.el4 > 0:1.2.1-6.el5)
svnmailer EPEL4 > EPEL5 (0:1.0.8-3.el4 > 0:1.0.8-2.el5)
pertusus AT free fr: libesmtp EPEL4 > EPEL5-testing (0:1.0.4-5.el4 > 0:1.0.4-2.el5)
perl-File-DesktopEntry EPEL4 > EPEL5-testing (0:0.04-5.el4 > 0:0.04-4.el5)
rnorwood AT redhat com: perl-BSD-Resource EPEL4-testing > EL5 (0:1.28-3.el4 > 0:1.28-1.fc6.1)
perl-Devel-Symdump EPEL4 > EPEL5 (1:2.07-3.el4.1 > 1:2.07-1.el5)
perl-TimeDate EPEL4 > EL5 (1:1.16-6.el4 > 1:1.16-5.el5)
rpm AT greysector net: tachyon EPEL4 > EPEL5 (0:0.97-6.el4 > 0:0.97-2.el5)
sheltren AT cs ucsb edu: python-elementtree EL4 > EL5 (0:1.2.6-5.el4.centos > 0:1.2.6-5)
wart AT kobold org: itcl EPEL4 > EPEL5 (0:3.3-0.9.RC1.el4 > 0:3.3-0.7.RC1.el5)
itk EPEL4 > EPEL5 (0:3.3-0.7.RC1.el4 > 0:3.3-0.4.RC1.el5)
wolfy AT nobugconsulting ro: logserial EPEL4 > EPEL5 (0:0.4.2-5.el4.1 > 0:0.4.2-4.el5)
----------------------------------------------------------------------
cdpr: mastahnke AT gmail com EPEL4 > EPEL5 (0:2.2.1-3.el4 > 0:2.2.1-2.el5)
cups-pdf: Fedora AT FamilleCollet com EPEL4 > EPEL5 (0:2.4.6-2.el4 > 0:2.4.6-1.el5)
device-mapper: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:1.02.21-1.el4 > 0:1.02.20-1.el5)
dmraid: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:1.0.0.rc14-6_RHEL4_U5 > 0:1.0.0.rc13-4.el5)
edac-utils: UNKNOWN OWNER (possibly Core package) EL4-updates > EL5 (0:0.9-7_el4 > 0:0.9-5.el5)
ethtool: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:6-1 > 0:5-1.el5)
frysk: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:0.0.1.2007.08.03-7.el4 > 0:0.0.1.2007.06.21.rh2-4.el5)
itcl: wart AT kobold org EPEL4 > EPEL5 (0:3.3-0.9.RC1.el4 > 0:3.3-0.7.RC1.el5)
itk: wart AT kobold org EPEL4 > EPEL5 (0:3.3-0.7.RC1.el4 > 0:3.3-0.4.RC1.el5)
jigdo: ianburrell AT gmail com EPEL4-testing > EPEL5-testing (0:0.7.3-4.el4 > 0:0.7.3-2.el5)
kyum: Jochen AT herr-schmitt de EPEL4-testing > EPEL5-testing (0:0.7.5-9.el4.1 > 0:0.7.5-4.el5)
libesmtp: pertusus AT free fr EPEL4 > EPEL5-testing (0:1.0.4-5.el4 > 0:1.0.4-2.el5)
logserial: wolfy AT nobugconsulting ro EPEL4 > EPEL5 (0:0.4.2-5.el4.1 > 0:0.4.2-4.el5)
lvm2: UNKNOWN OWNER (possibly Core package) EL4-updates > EL5 (0:2.02.27-2.el4_6.1 > 0:2.02.26-3.el5)
mercurial: dennis AT ausil us EPEL4 > EPEL5 (0:0.9.5-2.el4 > 0:0.9.3-1.el5)
MySQL-python: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:1.2.1_p2-1.el4.1 > 0:1.2.1-1)
nbtscan: foolish AT guezz net EPEL4 > EPEL5 (0:1.5.1-2.el4 > 0:1.5.1-1.el5)
obby: lmacken AT redhat com EPEL4 > EPEL5 (0:0.4.4-2.el4 > 0:0.4.4-1.el5)
openib: UNKNOWN OWNER (possibly Core package) EL4 > EL5-updates (0:1.2-7 > 0:1.2-6.el5_1.1)
perl-BSD-Resource: rnorwood AT redhat com EPEL4-testing > EL5 (0:1.28-3.el4 > 0:1.28-1.fc6.1)
perl-Devel-Symdump: rnorwood AT redhat com EPEL4 > EPEL5 (1:2.07-3.el4.1 > 1:2.07-1.el5)
perl-File-DesktopEntry: pertusus AT free fr EPEL4 > EPEL5-testing (0:0.04-5.el4 > 0:0.04-4.el5)
perl-TimeDate: rnorwood AT redhat com EPEL4 > EL5 (1:1.16-6.el4 > 1:1.16-5.el5)
plotutils: denis AT poolshark org EPEL4 > EPEL5-testing (0:2.5-5.el4 > 0:2.5-3.el5)
pstoedit: denis AT poolshark org EPEL4-testing > EPEL5-testing (0:3.45-2.el4 > 0:3.44-5.el5)
python-configobj: lmacken AT redhat com EPEL4 > EPEL5 (0:4.4.0-2.el4 > 0:4.4.0-1.el5)
python-docutils: a badger AT gmail com EPEL4 > EPEL5 (0:0.4-4.el4 > 0:0.4-3.el5)
python-elementtree: sheltren AT cs ucsb edu EL4 > EL5 (0:1.2.6-5.el4.centos > 0:1.2.6-5)
python-formencode: lmacken AT redhat com EPEL4 > EPEL5 (0:0.7.1-2.el4 > 0:0.7.1-1.el5)
python-genshi: jeff AT ocjtech us EPEL4 > EPEL5 (0:0.4.4-2.el4 > 0:0.4.4-1.el5)
python-GeoIP: mfleming+rpm AT enlartenment com EPEL4 > EPEL5-testing (0:1.2.1-7.el4 > 0:1.2.1-6.el5)
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
python-paste-script: lmacken AT redhat com EPEL4-testing > EPEL5 (0:1.3.6-1.el4 > 0:1.1-1.el5)
sg3_utils: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:1.22-3.1 > 0:1.20-2.1)
svnmailer: mfleming+rpm AT enlartenment com EPEL4 > EPEL5 (0:1.0.8-3.el4 > 0:1.0.8-2.el5)
system-config-lvm: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (0:1.0.23-1.0 > 0:1.0.22-1.0.el5)
tachyon: rpm AT greysector net EPEL4 > EPEL5 (0:0.97-6.el4 > 0:0.97-2.el5)
viewvc: bojan AT rexursive com EPEL4 > EPEL5-testing (0:1.0.4-2.el4 > 0:1.0.4-1.el5)
wpa_supplicant: UNKNOWN OWNER (possibly Core package) EL4 > EL5 (1:0.4.9-1.1.el4 > 1:0.4.8-10.1.fc6)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
buildsys@fedoraproject.org schrieb:
Jochen AT herr-schmitt de: kyum EPEL4-testing > EPEL5-testing (0:0.7.5-9.el4.1 > 0:0.7.5-4.el5)
Should be fixed.
Best Regards:
Jochen Schmitt
On Sun, Jan 20, 2008 at 02:42:55PM -0500, buildsys@fedoraproject.org wrote:
Broken upgrade path report for repositories EL4, EL4-updates, EPEL4, EPEL4-testing, EL5, EL5-updates, EPEL5, EPEL5-testing
pertusus AT free fr: libesmtp EPEL4 > EPEL5-testing (0:1.0.4-5.el4 > 0:1.0.4-2.el5)
perl-File-DesktopEntry EPEL4 > EPEL5-testing (0:0.04-5.el4 > 0:0.04-4.el5)rnorwood AT redhat com: perl-Devel-Symdump EPEL4 > EPEL5 (1:2.07-3.el4.1 > 1:2.07-1.el5)
Should be fixed.
-- Pat
On Sunday 20 January 2008 19:42:55 buildsys@fedoraproject.org wrote:
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
Was not this solved before? According to the cvs the last version available is
%changelog * Mon Jul 23 2007 Joel Andres Granados <jgranado at redhat dot com> - 0:1.1.4-1 - Build python-imaging for EPEL4 with the version from FC3. EPEL4 are packages - that can be installed in RHEL4**.
IIRC we had downgraded to cope with the inclusion of it in EL5. This was done before the official launch of EPEL so I have no clue what has gone wrong.
Regards,
On Mon, 21 Jan 2008 10:39:42 +0000, José Matos wrote:
On Sunday 20 January 2008 19:42:55 buildsys wrote:
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
Was not this solved before? According to the cvs the last version available is
%changelog
- Mon Jul 23 2007 Joel Andres Granados <jgranado at redhat dot com> -
0:1.1.4-1
- Build python-imaging for EPEL4 with the version from FC3. EPEL4 are
packages
that can be installed in RHEL4**.
IIRC we had downgraded to cope with the inclusion of it in EL5. This was
done before the official launch of EPEL so I have no clue what has gone wrong.
Depends on who "we" is. You cannot downgrade a package without asking the epel-signers to delete a newer package in the repo. The repo shows that an older package was pushed several months after the higher version:
http://download.fedora.redhat.com/pub/epel/4/SRPMS/
[ ] python-imaging-1.1.4-1.src.rpm 25-Jul-2007 11:03 418K [ ] python-imaging-1.1.6-3.el4.sr..> 02-Mar-2007 18:20 436K
Michael Schwendt wrote:
On Mon, 21 Jan 2008 10:39:42 +0000, José Matos wrote:
On Sunday 20 January 2008 19:42:55 buildsys wrote:
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
Was not this solved before? According to the cvs the last version available is
%changelog
- Mon Jul 23 2007 Joel Andres Granados <jgranado at redhat dot com> -
0:1.1.4-1
- Build python-imaging for EPEL4 with the version from FC3. EPEL4 are
packages
that can be installed in RHEL4**.
IIRC we had downgraded to cope with the inclusion of it in EL5. This was
done before the official launch of EPEL so I have no clue what has gone wrong.
Depends on who "we" is. You cannot downgrade a package without asking the epel-signers to delete a newer package in the repo. The repo shows that an older package was pushed several months after the higher version:
http://download.fedora.redhat.com/pub/epel/4/SRPMS/
[ ] python-imaging-1.1.4-1.src.rpm 25-Jul-2007 11:03 418K [ ] python-imaging-1.1.6-3.el4.sr..> 02-Mar-2007 18:20 436K
This is extremely strange. 1. This didn't come up before :) I've been checking the EPEL fairly regularly to see if python-imaging had any problems and it had never come up. Since the 1.1.4 appeared after 25-Jul, it should have screamed immediately (assuming that the 1.1.6 version was there)
2. I started co maintaining the EPEL package with jamatos around jul-2007, so the 1.1.6 version must have been there already (IMHO). Can we actually know who pushed it? Maybe it was automatically brought in :).
3. I checked my email logs and verified that the issue was discussed around Jul-2007 I cannot find earlier mails about the package ( I subscribed around Jul-2007, so apologies if I'm wrong)
Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right? Regards
On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
Michael Schwendt wrote:
On Mon, 21 Jan 2008 10:39:42 +0000, José Matos wrote:
On Sunday 20 January 2008 19:42:55 buildsys wrote:
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
Was not this solved before? According to the cvs the last version available is
%changelog
- Mon Jul 23 2007 Joel Andres Granados <jgranado at redhat dot com> -
0:1.1.4-1
- Build python-imaging for EPEL4 with the version from FC3. EPEL4 are
packages
that can be installed in RHEL4**.
IIRC we had downgraded to cope with the inclusion of it in EL5. This was
done before the official launch of EPEL so I have no clue what has gone wrong.
Depends on who "we" is. You cannot downgrade a package without asking the epel-signers to delete a newer package in the repo. The repo shows that an older package was pushed several months after the higher version:
http://download.fedora.redhat.com/pub/epel/4/SRPMS/
[ ] python-imaging-1.1.4-1.src.rpm 25-Jul-2007 11:03 418K [ ] python-imaging-1.1.6-3.el4.sr..> 02-Mar-2007 18:20 436K
This is extremely strange.
- This didn't come up before :) I've been checking the EPEL fairly regularly
to see if python-imaging had any problems and it had never come up. Since the 1.1.4 appeared after 25-Jul, it should have screamed immediately (assuming that the 1.1.6 version was there)
The upgradecheck script doesn't run automatically. The upgrade path between RHEL4 and 5 is not so important [1]. More important is the fact that packages in 4 and 5 are out-of-sync somehow and might differ in number of patches or even differ in %version. That's where the script helps.
[1] Generally, however, and more important for platforms like Fedora, upgrade path problems bear the risk of causing dependency problems (e.g. when the old dist links against other libs than the new dist).
- I started co maintaining the EPEL package with jamatos around jul-2007, so
the 1.1.6 version must have been there already (IMHO). Can we actually know who pushed it? Maybe it was automatically brought in :).
Yes, it can be seen who pushed it. File ownership tells that. But that doesn't say who should have removed the 1.1.6 version in case there was a request to do that.
- I checked my email logs and verified that the issue was discussed around Jul-2007
I cannot find earlier mails about the package ( I subscribed around Jul-2007, so apologies if I'm wrong)
Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right?
Mail the repo admins in accordance with the EPEL FAQ in the Wiki and request removal of the 1.1.6 package. (it is enough to delete the src.rpm and let repoprune kill the various binaries)
Michael Schwendt wrote:
On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
Michael Schwendt wrote:
On Mon, 21 Jan 2008 10:39:42 +0000, José Matos wrote:
On Sunday 20 January 2008 19:42:55 buildsys wrote:
python-imaging: jamatos AT fc up pt EPEL4 > EL5 (0:1.1.6-3.el4 > 0:1.1.5-5.el5)
Was not this solved before? According to the cvs the last version available is
%changelog
- Mon Jul 23 2007 Joel Andres Granados <jgranado at redhat dot com> -
0:1.1.4-1
- Build python-imaging for EPEL4 with the version from FC3. EPEL4 are
packages
that can be installed in RHEL4**.
IIRC we had downgraded to cope with the inclusion of it in EL5. This was
done before the official launch of EPEL so I have no clue what has gone wrong.
Depends on who "we" is. You cannot downgrade a package without asking the epel-signers to delete a newer package in the repo. The repo shows that an older package was pushed several months after the higher version:
http://download.fedora.redhat.com/pub/epel/4/SRPMS/
[ ] python-imaging-1.1.4-1.src.rpm 25-Jul-2007 11:03 418K [ ] python-imaging-1.1.6-3.el4.sr..> 02-Mar-2007 18:20 436K
This is extremely strange.
- This didn't come up before :) I've been checking the EPEL fairly regularly
to see if python-imaging had any problems and it had never come up. Since the 1.1.4 appeared after 25-Jul, it should have screamed immediately (assuming that the 1.1.6 version was there)
The upgradecheck script doesn't run automatically. The upgrade path between RHEL4 and 5 is not so important [1]. More important is the fact that packages in 4 and 5 are out-of-sync somehow and might differ in number of patches or even differ in %version. That's where the script helps.
[1] Generally, however, and more important for platforms like Fedora, upgrade path problems bear the risk of causing dependency problems (e.g. when the old dist links against other libs than the new dist).
- I started co maintaining the EPEL package with jamatos around jul-2007, so
the 1.1.6 version must have been there already (IMHO). Can we actually know who pushed it? Maybe it was automatically brought in :).
Yes, it can be seen who pushed it. File ownership tells that. But that doesn't say who should have removed the 1.1.6 version in case there was a request to do that.
- I checked my email logs and verified that the issue was discussed around Jul-2007
I cannot find earlier mails about the package ( I subscribed around Jul-2007, so apologies if I'm wrong)
Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right?
Mail the repo admins in accordance with the EPEL FAQ in the Wiki and request removal of the 1.1.6 package. (it is enough to delete the src.rpm and let repoprune kill the various binaries)
ok. sent mail to EPEL signers group. :) Thx for the help. Regards
On 21.01.2008 16:30, Joel Andres Granados wrote:
Michael Schwendt wrote:
On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
Michael Schwendt wrote: Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right?
Mail the repo admins in accordance with the EPEL FAQ in the Wiki and request removal of the 1.1.6 package. (it is enough to delete the src.rpm and let repoprune kill the various binaries)
ok. sent mail to EPEL signers group. :)
Hmmm. Is it wise to remove it? If I understood the discussion correctly then users that already have the currently newest version of python-imaging in EPEL4 installed will never get a update should there ever be released one with a EVRN lower then (none):1.1.6-3.el4.
On the other hand: we cannot increase the epoch only in EPEL4 because then the upgrade path to RHEL5 is broken (still/again).
Which of the two things is worse?
Cu knurd
On Mon, 21 Jan 2008 18:59:45 +0100, Thorsten Leemhuis wrote:
On 21.01.2008 16:30, Joel Andres Granados wrote:
Michael Schwendt wrote:
On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
Michael Schwendt wrote: Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right?
Mail the repo admins in accordance with the EPEL FAQ in the Wiki and request removal of the 1.1.6 package. (it is enough to delete the src.rpm and let repoprune kill the various binaries)
ok. sent mail to EPEL signers group. :)
Hmmm. Is it wise to remove it? If I understood the discussion correctly then users that already have the currently newest version of python-imaging in EPEL4 installed will never get a update should there ever be released one with a EVRN lower then (none):1.1.6-3.el4.
But is the newer package in EPEL4 maintained actively? In CVS it is back at 1.1.4 already. Will any bug-fix/security-fix released for RHEL4 be ported to the >1.1.6 pkg in EPEL4? If that doesn't happen, keeping the 1.1.6 brown paper-bag in the repo makes no sense.
On the other hand: we cannot increase the epoch only in EPEL4 because then the upgrade path to RHEL5 is broken (still/again).
Which of the two things is worse?
The third thing. ;) Replacing a pkg from RHEL ;-P and an attitude like "damage is done, we can't revert it". Next time it happens with a different package, you won't revert it either?
On 21.01.2008 19:33, Michael Schwendt wrote:
On Mon, 21 Jan 2008 18:59:45 +0100, Thorsten Leemhuis wrote:
On 21.01.2008 16:30, Joel Andres Granados wrote:
Michael Schwendt wrote:
On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
Michael Schwendt wrote: Don't know what to make of it. So I assume from "You cannot downgrade a package without asking the epel-signers to delete a newer package", that the solution is to delete the newer package. right?
Mail the repo admins in accordance with the EPEL FAQ in the Wiki and request removal of the 1.1.6 package. (it is enough to delete the src.rpm and let repoprune kill the various binaries)
ok. sent mail to EPEL signers group. :)
Hmmm. Is it wise to remove it? If I understood the discussion correctly then users that already have the currently newest version of python-imaging in EPEL4 installed will never get a update should there ever be released one with a EVRN lower then (none):1.1.6-3.el4.
But is the newer package in EPEL4 maintained actively? In CVS it is back at 1.1.4 already. Will any bug-fix/security-fix released for RHEL4 be ported to the >1.1.6 pkg in EPEL4? If that doesn't happen, keeping the 1.1.6 brown paper-bag in the repo makes no sense.
Sure, it would need to be discussed which spec file we'd continue to maintain.
On the other hand: we cannot increase the epoch only in EPEL4 because then the upgrade path to RHEL5 is broken (still/again). Which of the two things is worse?
The third thing. ;) Replacing a pkg from RHEL ;-P
That would only happen on update afaics.
and an attitude like "damage is done, we can't revert it". Next time it happens with a different package, you won't revert it either?
I didn't suggest that. I actually think removing is best as well. But doing such things should not be the decision of those that have access to the repo alone, thus I asked for options here on the list.
CU knurd
On Mon, 21 Jan 2008 20:01:53 +0100, Thorsten Leemhuis wrote:
On the other hand: we cannot increase the epoch only in EPEL4 because then the upgrade path to RHEL5 is broken (still/again). Which of the two things is worse?
The third thing. ;) Replacing a pkg from RHEL ;-P
That would only happen on update afaics.
Only because RHEL4 does not include python-imaging at all. Still, even for fresh install upgrades from EL4 -> EL5 this package would be downgraded. Anything fixed in 1.1.6 might reappear due to this downgrade. The python-imaging ChangeLog is not short.
The least to expect would be to include RHEL5's package _as is_ in EPEL4 and not downgrade it to 1.1.4 and not upgrade it to 1.1.6 either.
On 21.01.2008 20:01, Thorsten Leemhuis wrote:
I actually think removing is best as well. But doing such things should not be the decision of those that have access to the repo alone, thus I asked for options here on the list.
FYI: python-imaging-1.1.6-3.el4 was removed with the push that happened earlier today.
Cu knurd
Thorsten Leemhuis wrote:
On 21.01.2008 20:01, Thorsten Leemhuis wrote:
I actually think removing is best as well. But doing such things should not be the decision of those that have access to the repo alone, thus I asked for options here on the list.
FYI: python-imaging-1.1.6-3.el4 was removed with the push that happened earlier today.
Cu knurd
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Great !!
On Jan 20, 2008, at 11:42 AM, buildsys@fedoraproject.org wrote:
sheltren AT cs ucsb edu: python-elementtree EL4 > EL5 (0:1.2.6-5.el4.centos > 0:1.2.6-5)
Any idea where the script is pulling this EL4 package in? The one I built (and the only one I see in the EPEL repo) is 0:1.2.6-0.6.el4. The fact that there is a 'centos' in the release tag makes me wonder if this is getting pulled in from some CentOS repo...
-Jeff
On Tue, 22 Jan 2008 15:31:58 -0800, Jeff Sheltren wrote:
On Jan 20, 2008, at 11:42 AM, buildsys wrote:
sheltren AT cs ucsb edu: python-elementtree EL4 > EL5 (0:1.2.6-5.el4.centos > 0:1.2.6-5)
Any idea where the script is pulling this EL4 package in? The one I built (and the only one I see in the EPEL repo) is 0:1.2.6-0.6.el4. The fact that there is a 'centos' in the release tag makes me wonder if this is getting pulled in from some CentOS repo...
EL4 = CentOS 4.6 EL5 = CentOS 5.1
It's included in the core/base repo of CentOS 4.6, but not RHEL 4.6. Hmmm...
http://mirror.centos.org/centos/4/os/SRPMS/python-elementtree-1.2.6-5.el4.ce...
P.S. It's a coincidence that you are listed as the owner for a CentOS package. The script assumes that all package owners are covered by the same owners.list DB.
On Jan 22, 2008, at 4:26 PM, Michael Schwendt wrote:
On Tue, 22 Jan 2008 15:31:58 -0800, Jeff Sheltren wrote:
On Jan 20, 2008, at 11:42 AM, buildsys wrote:
sheltren AT cs ucsb edu: python-elementtree EL4 > EL5 (0:1.2.6-5.el4.centos > 0:1.2.6-5)
Any idea where the script is pulling this EL4 package in? The one I built (and the only one I see in the EPEL repo) is 0:1.2.6-0.6.el4. The fact that there is a 'centos' in the release tag makes me wonder if this is getting pulled in from some CentOS repo...
EL4 = CentOS 4.6 EL5 = CentOS 5.1
It's included in the core/base repo of CentOS 4.6, but not RHEL 4.6. Hmmm...
http://mirror.centos.org/centos/4/os/SRPMS/python-elementtree-1.2.6-5.el4.ce...
P.S. It's a coincidence that you are listed as the owner for a CentOS package. The script assumes that all package owners are covered by the same owners.list DB.
Ahh, that makes sense then. I had thought EL4 was referring to RHEL-4, not CentOS-4 since the builders are using RHEL. The reason for this package being in EPEL-4 at all is due to the fact that it is in CentOS and not in RHEL (and it's needed for yum, createrepo, etc.).
Thanks, Jeff
epel-devel@lists.fedoraproject.org
-
Fedora Koji Build System -
Jeff Sheltren -
Jochen Schmitt -
Joel Andres Granados -
José Abílio Matos -
Michael Schwendt -
Patrice Dumas -
Thorsten Leemhuis