-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase libsolv and add epoch #863
base: rpm/develop
Are you sure you want to change the base?
Conversation
@@ -1,60 +1,59 @@ | |||
%global python3_pkgversion 3.11 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to drop the python 3.11 bindings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably want to keep it even :D Hence why I [wip] 'ed it
I did the initial copy over, but have not had a chance to update it to also build for python 3.11
* Mon Nov 20 2023 Patrick Creech <[email protected]> - 0.7.22-6 | ||
- Obsolete python39-libsolv as well | ||
* Mon Jan 22 2024 Patrick Creech <[email protected]> - 1:0.7.20-6 | ||
- Rebase libsolv and add epoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Rebase libsolv and add epoc | |
- Rebase libsolv and add epoch |
packages/libsolv/libsolv.spec
Outdated
Version: 0.7.22 | ||
Version: 0.7.20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we downgrading things?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
additionally: how are we going to handle EL9 which ships libsolv-0.7.24 today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and what about https://github.com/pulp/pulp_rpm/blob/main/requirements.txt#L7 (this has been true since pulp_rpm 3.17, which is pulpcore 3.16+)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have confirmed with pulp that while the requirements.txt for pip is 0.7.21, the functionality required should be back-ported into the OS provided libsolv. We should be able to modify that requirements.txt via spec to loosen the requirement. (it's not exactly true in a purely upstream pip installed context, hence the need for spec modificaiton).
Ideally, we should probably stop shipping libsolv on el9. Revert back to using system libsolv, and only ship 3.11 bindings for it. As far as "how", i'm not entirely sure. I need to do a little research in this space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if we can avoid building the lib and only do the bindings, that'd be awesome.
But the last time I looked at this, I ran away pretty quickly, as the bindings are essentially generated from the lib source and you can't build them w/o the lib (or, if you build both and only ship the bindings, who the hell guarantees that the lib from the OS and the bindings from the lib you don't ship actually match up)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so after some research and some help from fedora-devel matrix channel, we can build the python binding in a statically linked way. I played around with this locally, and it also appears to be the way solv is distributed by pypi. Therefore it won't override system libsolv, but won't use it either. Meaning we can safely decouple from system libsolv, unless we have good reason to keep it coupled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so you build a pythonX-solv that contains a copy of libsolv but that's only used inside the Python X context? Fair
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup :D best way out of this mess I can figure out.
e488998
to
3f8055a
Compare
3f8055a
to
bffd875
Compare
Still a little "WIP", but I think I have the strategy. We introduce "libsolv" with an epoch, but otherwise 1-1 with system libsolv. This should fix the el8 issue. (still need to fix it to only build on el8) We also introduce a 'python-solv' package for both el8 and el9, which provides a python3.11-solv. This should allow us to not be version locked with system libsolv, and keep us out of the game of dealing with an epoch on el9, and we can get out of this mess with libsolv when we drop el8. |
So I briefly tested the EL9 python-solv package, and besides the wrong name, it seems to have a working python solv stack, without being linked to the system libsolv. Yay. Just to unfuck my brain, the plan is to:
Question: Would a version like |
Sadly, no. There is not a way to "upgrade" out of a module, and we are in the module at this point. I'm not a fan of epochs either, but this is kinda the reason they exist in RPM land, and translate better. We will never "upgrade" out of this state sadly. Currently fleshing out the small updates, should be g2g soon |
4051d18 will need to be removed once we are ready to merge. This commit is only to bypass the version/release check that keeps failing due to rebasing on a new version/release with epoc. It really doesn't like the release for some reason. |
[rpm-copr test] |
202a039
to
4051d18
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
python3-solv is still in the el9 comos, but should not?
There's got to be a way around this error
[test rpm-copr] as I have no idea why it failed and the logs are gone |
el9 comps still contain |
aha, building |
This PR will be superseded by two other PRs breaking the individual items apart. python-solv - #938 |
Can we close this @pcreech ? |
No description provided.