Opened 12 years ago
Last modified 8 years ago
#36318 assigned update
Update rpm to 4.9?
Reported by: | twic@… | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.2 |
Keywords: | Cc: | afb@…, cooljeanius (Eric Gallager) | |
Port: | rpm |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
The current version of the rpm port is 4.4.9:
browser:trunk/dports/sysutils/rpm/Portfile
There is a separate port for 4.5:
browser:trunk/dports/sysutils/rpm45/Portfile
The latest stable version upstream is 4.9.1.3:
http://www.rpm.org/wiki/Download
And, FWIW, that's what's in current versions of Fedora:
https://apps.fedoraproject.org/packages/rpm
There is a 4.10.0:
But it's not widely used yet.
Is there any chance of updating MacPorts's version of RPM to something more recent? Is this something i could help with?
I realise that there are also 5.x versions, but this is a fork. I'm interested in having a recent 4.x version for consistency with Fedora and related Linuxes.
Change History (9)
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | afb@… added |
---|---|
Description: | modified (diff) |
Owner: | changed from macports-tickets@… to n3npq@… |
comment:2 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 12 years ago by n3npq@…
Consistency with ... what?
rpm-4.4.9 and rpm-4.9.1.3 are entirely different projects.
comment:4 Changed 12 years ago by twic@…
I assume Ryan means consistency with the other RPM ports, all of which have version numbers; if there are several forks of equal validity, then it's inconsistent for one to not have a version number.
I should say that i have no knowledge of the history of RPM; i couldn't find anything about it post-2007 with a quick google, but would be interested to learn. 4.9 is not a successor to 4.4? What about 4.5?
So, we would have to have a new port for 4.9? Or, perhaps, for the fork that 4.9 is part of? Any idea how much work that would be? Is that a question of copying the 4.4, 4.5, or 5.x portfile and hacking?
comment:5 Changed 12 years ago by n3npq@…
rpm aming (and version) inconsistencies cannot be solved by MacPorts.
Yes rpm-4.9.1 is not a successor to rpm-4.4.9 (which is obsolete for 5+ years already)
rpm-4.5 *is* a successor to rpm-4.4.9 (but the last usage of rpm-4.5 is in PLD, which has starting to switch to rpm-5.4.10 because there is no upgrade path for rpm-4.5 because of not only versioning, but functional/feature, incompatibilities in rpm-4.9.1 and its predecessors)
rpm-4.9.1 is a different project, and a new port. Yes I have an idea how much work is involved, but you are asking the "competition" in an active and hostile fork what work is involved.
So far there has bveen vanishingly small interest from Fedora in porting rpm-4.9.1 -> MacPorts.
There is also vanishingly small interest in MacPorts using rpm (except for rpm2cpio.sh to extract sourcxes/patches from linux packaging).
comment:6 Changed 12 years ago by afb@…
Adding some rpm48* and rpm49 and rpm410 ports could be done, just as there are rpm52 and rpm53 and rpm54 ports already.
- rpm-4.8.0 is the version used by RHEL, presumably covered by "related Linuxes" since it is a downstream distribution ?
But for the things that MacPorts are doing (i.e. "port rpm" packaging), using rpm-4.4.9 is fine and for the rest there's rpm2cpio...
For reference there are some similar discussions in Homebrew and in FreeBSD, both of which are carrying both the forks of RPM.
comment:8 Changed 12 years ago by cooljeanius (Eric Gallager)
I made a ticket for 4.11 now: #38978
For reference there are some similar discussions in Homebrew and in FreeBSD, both of which are carrying both the forks of RPM.
I see you've submitted pull requests to Homebrew for both forks of RPM, but it looks like they haven't been accepted yet...?
comment:9 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | n3npq@… deleted |
---|---|
Status: | new → assigned |
It seems like for consistency, "rpm" should be renamed to "rpm44", and then a new "rpm49" port should be created.