Description of problem: Would it be possible to have the ipmctl build updated to v03.00.00.0468 (https://github.com/intel/ipmctl/releases/tag/v03.00.00.0468)? Version-Release number of selected component (if applicable): ipmctl-0:02.00.00.3885-1.el8.x86_64 Looks like EPEL9 might have a spec that can be simply re-used. https://src.fedoraproject.org/rpms/ipmctl
I will look at moving earlier version of EPEL to 03.00.00.0468.
FEDORA-EPEL-2023-67f6e0b2a8 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-67f6e0b2a8
FEDORA-EPEL-2023-e53f5e87f4 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e53f5e87f4
FEDORA-2023-394dbcf6cc has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-394dbcf6cc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-394dbcf6cc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-67f6e0b2a8 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-67f6e0b2a8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-e53f5e87f4 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e53f5e87f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-67f6e0b2a8 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2023-e53f5e87f4 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-394dbcf6cc has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
Hrm. This update seems to have broken existing EL8 software as the ipmctl-2 shared library (libipmctl.so.4) is no longer available for software that was built prior to this update. When this was updated, I was assuming that a -compat package would have been made not to break existing software. I guess I should have been explicit about that in my request. Can we please get a -compat package to provide the previous major library version libipmctl.so.4 that any already-compiled software will be requiring? Thanks!
You may want to put a request in on the GitHub site https://github.com/intel/ipmctl as I would guess it would be useful on other distros as well. The main change between the current version and the previous one is added support for 300 series so I would guess that most systems will work fine with the older version. I do not see a trivial way of creating this compat library. Is there a reason the other packages cannot be recompiled to use the newer library?
@steven.pontsler > You may want to put a request in on the GitHub site https://github.com/intel/ipmctl as I would guess it would be useful on other distros as well. This is not an upstream (https://github.com/intel/ipmctl) issue. This is a distro-specific packaging issue. Different distros in fact have different solutions. SUSE and Ubuntu/Debian distros package concurrent library versions with the SOVERSION embedded in their name (i.e. libipmctl1, libipmctl2, libipmctl3, etc.) to allow multiple SOVERSIONs of the library to coexist which allows software built for version 2 to work while software built for version 3 can also work because both libipmctl.so.{2,3} are installed concurrently. RH distros approach this differently and only have one "main" package with the latest SOVERSION in it. But in order to not break an entire ecosystem of already built software that people install from third-party repos (remember, the whole world does not build their software stacks from source!) when updating a package that includes a SOVERSION update, it is common practice to build the older SOVERSION(s) in a *-compat (i.e. ipmctl2-compat) package. > The main change between the current version and the previous one is added support for 300 series so I would guess that most systems will work fine with the older version. So this brings up a good question. Did the ABI (i.e. API) change in version 3 in any way that makes the version 3 API incompatible with the version 2 API or was it all just "added" (API) functionality (or internal to the API changes), and thus preserving the existing v2 API? > I do not see a trivial way of creating this compat library. It's simply repackaging v2 into a new RPM, named perhaps ipmctl-compat or compat-ipmctl2, if you follow how RH handles this. A specific example is https://git.centos.org/rpms/compat-openssl10/blob/c8/f/SPECS/compat-openssl10.spec, or an alternative, "all in one" method: https://git.centos.org/rpms/hwloc/blob/c8/f/SPECS/hwloc.spec. This latter one is a great example of a library that changes is ABI/API from v1 to v2 but recognizes that every piece of software cannot adopt that API change overnight. > Is there a reason the other packages cannot be recompiled to use the newer library? Yes, because there are existing package repos that have RPMs that currently depend on libipmctl.so.2. Requiring ISVs to have to rebuild, re-qualify and re-release software (on an emergency basis, even, given that such ISV's software was broken overnight, without warning, leaving their customers in the lurch with broken systems when they did they daily upgrades for security compliance for example) is not really nice, or scalable. I would tend to guess just about no ISV doing any QA on any of their software can rush a fix like this out to their customers with the kind of urgency that broken systems would demand. But this further raises the question of v2/v3 API/ABI compatibility. If software written for v2 can simply "be recompiled" with the v3 ipmctl, that indicates to me that the API/ABI did not in fact change. Instead, it would have been much better for those existing installations to have simply had their ipmctl-2.x upgraded to impctl-3.x and then the software on their systems that require libipmctl.so.2 would have made dnf install the ipmctl-compat package as a new package in the upgrade transaction, preserving the functionality of those systems. That all said, I do want to make a specific point of my question earlier whether the ABI/API was actually broken between versions 2 and 3 (i.e existing interfaces changed their signature, etc.) or if the changes were all just internal and not API/ABI affecting and/or extending (but not changing) the external ABI/API (i.e. function signatures, etc.).
The ABI/API is very similar between ipmctl 2.x and 3.x. I believe the most common functions are unchanged though there are some breaking changes. I'll take a look at what can be done.
Hi Steven, (In reply to Steven Pontsler from comment #13) > The ABI/API is very similar between ipmctl 2.x and 3.x. I believe the most > common functions are unchanged though there are some breaking changes. But if the solution provided previously "just recompile" is valid and comprehensive then there can't be any breaking API/ABI can there? I would have to update my source for any breaking changes wouldn't I? > I'll take a look at what can be done. I'm not really asking for you modify your v3. If it breaks the API/ABI then that is fine, if it is necessary. What I am driving at here is was the SOVERSION bump really necessary in v3 (or maybe even v2)? The SOVERSION (i.e. the library major version) should only be bumped when the API/ABI gets broken in a non-backward way. That is, if some existing interface changes. If the only change is new interfaces, then a SOVERSION bump is not necessary and is desirable as it avoids these kinds of problems with existing software wanting to find a certain SOVERSION. Indeed, some software packages/libraries strive to maintain backward compatibility and only break their ABI very infrequently, due to the upheaval that bumping the SOVERSION causes. Look at glibc for example. As old (and still maintained) as that software is, it's SOVERSION is still only 6.
If the source used one of the modified/removed functions than it would not compile and would need to be updated. If the source only used functions that were not modified (which I would guess is the most common case) then I would expect it to compile without modification. I have requested a compat project.
Hi @steven.pontsler I don't mean to belabour this issue, but I just want to make sure my understanding is 100% clear... (In reply to Steven Pontsler from comment #15) > If the source used one of the modified/removed functions than it would not > compile and would need to be updated. Ahhh. So to be perfectly clear, the previous suggestion in comment #11: "Is there a reason the other packages cannot be recompiled to use the newer library?" is not a blanket solution that everyone could implement that simply (i.e. just a recompile). Some people's software might need to be modified to account for API breaking changes between v2 and v3, yes? > If the source only used functions that > were not modified (which I would guess is the most common case) then I would > expect it to compile without modification. I see. That does seem to indicate that while perhaps the majority of the API did not change between v2 and v3, there are some v2 interfaces which did change, yes? > I have requested a compat project. That's great! I do have the start of an ipmctl-compat.spec here that does seem to build a working libipmctl.so.4 in a libipmctl-compat subpackage. It's right now also building the main package, and probably doing more moving of things to "ipmctl-compat" that is necessary, but it's really just a PoC on my end to ensure that the concept is sane. With your better understanding of all of the moving parts between v2 and v3 you could probably safely remove some of the "compat-ing" that I have done. I.e. I suspect that probably ipmctl-compat (with the ipmctl binary and manpages, etc.) could be eliminated entirely and the v3 version used on systems that might need libipmctl.so.4 just for library compatibility. In fact I will probably work on that paring down today as we need to get something together that we can give to customers afflicted by this breakage ASAP.
I believe there is only one breaking change or maybe 2.
FEDORA-EPEL-2023-965889acfa has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-965889acfa
@brian.murrell I created a compat package please see if it meets your needs. It is ipmctl-compat-02.00.00.3885 available at https://koji.fedoraproject.org/koji/buildinfo?buildID=2151957 It is the 2.0 code.
FEDORA-EPEL-2023-965889acfa has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-965889acfa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi Steven. Apologies for the delay on this, but somebody on our team was able to test the update and it seems to work just fine. He only installed the libipmctl-compat package as the ipmctl-compat package is and should be superfluous. Much thanks for all of your time and attention on this.
Hi Steven. Just to confirm, when you push your update above to EPEL-8, there will also be an EPEL-7 build, yes, since that too seems to have been bumped to v3?
If it looks good on EPEL-8 and gets accepted then I'll create one for EPEL 7 as well.
@steven.pontsler Just wanted to point out my confirmation of the compat build above in case you missed it. I left a confirmation on bodhi also.
Hi @steven.pontsler I wonder if you have made any progress with getting this ipmctl-compat into EPEL.
FEDORA-EPEL-2023-965889acfa has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
The epel 7 branch was posted 3 days ago. The older version for Fedora Iam still working on.
Hi @steven.pontsler I'm still not seeing ipmctl-compat in EPEL-7. Did something get dropped?
I see it when I search for it. Looks like it is still in testing. https://bodhi.fedoraproject.org/updates/?packages=ipmctl-compat-02.00.00.3885 It looks like it will be pushed to stable in 1 day if no negative feedback is received. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-aa3ef32878
Oh. I guess I misunderstood. I thought comment#27 was saying it was generally available. I will advise our customers that it should be available RSN. :-)