(Slightly) incompatible update for EPEL 8 and 9: p7zip -> 7zip #367

Open
opened 2026-06-16 21:32:24 +00:00 by salimma · 9 comments
Contributor

I just filed https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/UI3SZQWHFQYGQHE4EHKEYAT72WRJEUGD/ proposing to replace p7zip with 7zip in EPEL 8 and 9 (EPEL 10 already ships 7zip and never shipped p7zip)

Accidentally left out EPEL 8 from the initial email, I'll reply with a correction and link this issue

I just filed https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/UI3SZQWHFQYGQHE4EHKEYAT72WRJEUGD/ proposing to replace p7zip with 7zip in EPEL 8 and 9 (EPEL 10 already ships 7zip and never shipped p7zip) Accidentally left out EPEL 8 from the initial email, I'll reply with a correction and link this issue
Owner

Seems reasonable at first glance.

Are there any other packages known to be affected? I see a few packages that (build)require p7zip and/or p7zip-plugins. Even if the rawhide versions of these packages built fine with 7zip, the EPEL versions may be older and might not. An impact check in a copr would help check this.

  • playonlinux
  • GraphicsMagick
  • dc3dd
  • lesspipe
  • quilt
  • conky-manager
  • retrace-server

I'll also suggest doing EPEL 9 only first, and then based on those results deciding if it's worth the risk to do the same in EPEL 8.

Seems reasonable at first glance. Are there any other packages known to be affected? I see a few packages that (build)require p7zip and/or p7zip-plugins. Even if the rawhide versions of these packages built fine with 7zip, the EPEL versions may be older and might not. An impact check in a copr would help check this. * playonlinux * GraphicsMagick * dc3dd * lesspipe * quilt * conky-manager * retrace-server I'll also suggest doing EPEL 9 only first, and then based on those results deciding if it's worth the risk to do the same in EPEL 8.
Author
Contributor
That makes perfect sense. I've created https://copr.fedorainfracloud.org/coprs/salimma/7zip-transition-epel9/
Author
Contributor

GraphicsMagick is in a bad state

  • CVEs
  • I suspect it's missing a runtime dep on 7za, having p7zip in the BR helps the compile time check but it might crash at runtime
  • it still uses patchN on epel9 so the SRPM won't even regenerate

So I'm checking the others first, and might just propose updating and cleaning up GM in Rawhide and backporting it to EPEL 9 too.

GraphicsMagick is in a bad state * CVEs * I suspect it's missing a runtime dep on 7za, having p7zip in the BR helps the compile time check but it might crash at runtime * it still uses patchN on epel9 so the SRPM won't even regenerate So I'm checking the others first, and might just propose updating and cleaning up GM in Rawhide and backporting it to EPEL 9 too.
Author
Contributor

OK, everything builds fine except GraphicsMagick that I'll probably try and fix both in Rawhide and in epel9 - given the CVEs I'd rather fix Fedora as well and fast-forward it to EPEL - there's already an issue open asking to update EPEL 8 and 9 anyway

OK, everything builds fine except GraphicsMagick that I'll probably try and fix both in Rawhide and in epel9 - given the CVEs I'd rather fix Fedora as well and fast-forward it to EPEL - there's already an issue open asking to update EPEL 8 and 9 anyway
Author
Contributor

GraphicsMagick also built using @carlwgeorge 's suggestion of just grabbing the URL for the SRPM from Koji and uploading that. So we do have a COPR bug in that it can't regenerate a patchN SRPM even for targets like EPEL 9 where that's actually valid, but it should not be a blocker for actual builds in Koji (and anyway is not due to this change)

are we ... good to go?

GraphicsMagick also built using @carlwgeorge 's suggestion of just grabbing the URL for the SRPM from Koji and uploading that. So we do have a COPR bug in that it can't regenerate a patchN SRPM even for targets like EPEL 9 where that's actually valid, but it should not be a blocker for actual builds in Koji (and anyway is not due to this change) are we ... good to go?
Author
Contributor

@carlwgeorge wrote in #367 (comment):

Seems reasonable at first glance.

Are there any other packages known to be affected? I see a few packages that (build)require p7zip and/or p7zip-plugins. Even if the rawhide versions of these packages built fine with 7zip, the EPEL versions may be older and might not. An impact check in a copr would help check this.

* playonlinux

* GraphicsMagick

* dc3dd

* lesspipe

* quilt

* conky-manager

* retrace-server

I'll also suggest doing EPEL 9 only first, and then based on those results deciding if it's worth the risk to do the same in EPEL 8.

conky-manager and retrace-server don't seem to be branched for epel9

@carlwgeorge wrote in https://forge.fedoraproject.org/epel/steering/issues/367#issuecomment-822266: > Seems reasonable at first glance. > > Are there any other packages known to be affected? I see a few packages that (build)require p7zip and/or p7zip-plugins. Even if the rawhide versions of these packages built fine with 7zip, the EPEL versions may be older and might not. An impact check in a copr would help check this. > > * playonlinux > > * GraphicsMagick > > * dc3dd > > * lesspipe > > * quilt > > * conky-manager > > * retrace-server > > > I'll also suggest doing EPEL 9 only first, and then based on those results deciding if it's worth the risk to do the same in EPEL 8. conky-manager and retrace-server don't seem to be branched for epel9
Owner

As per voted on today's EPEL Steering Committee meeting, this was approved to proceed on epel9 (with appropriate announcements).

epel8 incompat update vote will wait on conky-manager, retrace-server and other epel8 build results.

As per voted on today's EPEL Steering Committee meeting, this was approved to proceed on epel9 (with appropriate announcements). epel8 incompat update vote will wait on conky-manager, retrace-server and other epel8 build results.
Author
Contributor

Should I keep this open for epel8 or should we close and I'll open a new one for that?

Should I keep this open for epel8 or should we close and I'll open a new one for that?
Owner

I think it's fine to keep using this one ticket.

I think it's fine to keep using this one ticket.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
epel/steering#367
No description provided.