Honors /usr/lib/os-release when /etc/os-release is not available
#262
Conversation
|
Note : the patch seems back-portable to the UPDATE 2020-06-02 : Not anymore, since it relies on #247 (not back-ported) too now. |
|
Up @nir0s please 🙄 |
|
One more "up" for 2020. |
|
Fellas, I truly apologize, but I indeed hardly have any capacity to deal with issues nowadays. I'd appreciate adding collaborators. Any volunteers? |
|
Well, thanks for your answer @nir0s. I can't go full-time on it of course, but as I now maintain a project depending completely on yours, I'm indirectly interesting in Bye, take care. |
I think it's good and fair to be realistic and open about it, thanks for that. And thanks for your work on distro in general 🙏 At the same time I think it's a bit sad also e.g. because of the 9000+ projects dependening on If I may ask, are your capacity constraints temporary or expected long-term? If long-term, maybe it makes sense to turn this project into a new GitHub org then. It's rather easy to do technically — create the org, then do a repo transfer (which moves all issues and PRs just like that, then add people) — and it may communicate better that the project has become the effort of a new team if you're saying goodbye long-term. At least one other trusted person will also need PyPI access for a full transition. I hope I'm being respectful here, I didn't intend otherwise. What do you think?
Speaking for myself, I will not be able to shoulder much load here but if there are other active contributors, I may be able to join and help a bit myself too (after my current sprint on https://github.com/git-big-picture/git-big-picture has cooled down more). |
hartwork
left a comment
hartwork
left a comment
There was a problem hiding this comment.
I had a closer look now. Given what the spec says about /usr/lib/os-release I think merging some version of this pull request will be important to do justice to the specification. So thanks to @HorlogeSkynet for working on this matter! 🙏
Below are my findings. Some of them are picky… but with good intentions. I'm happy to learn I misunderstood or overlooked something. Best, Sebastian
Co-authored-by: Sebastian Pipping <[email protected]>
hartwork
left a comment
hartwork
left a comment
There was a problem hiding this comment.
@HorlogeSkynet looks good to me now, thanks for your contribution and your patience! 🙏
You're very welcome, sorry for this little leftover that didn't catch my attention sooner. |
|
@nir0s this PR is ready and waiting for your approval by now. Do you have a minute? |
|
@nir0s any news? |
|
@nir0s how can we move forward? |
|
So sad only pull requests "brandishing" the |
sethmlarson
left a comment
sethmlarson
left a comment
There was a problem hiding this comment.
Overall this looks like a good improvement. Had some comments for you:
tests/resources/testdistros/distro/usrlibosreleaseonly/usr/lib/os-release
Show resolved
Hide resolved
sethmlarson
left a comment
sethmlarson
left a comment
There was a problem hiding this comment.
Going to approve since the reference comment is optional.
|
There are conflicts now, though. @HorlogeSkynet. |
🙄 I'll try to rebase soon. |
@HorlogeSkynet let me know if you need help |
|
@nir0s I went for a manual merge, all good now ✅ |
4 participants
Hey over here 👋
So, there is
a bugan unexpected behavior with distro in very "lite" environments, when for example even/etc/os-releaseis not available.It actually appears that we should be dealing with
/usr/lib/os-releasein such cases (reference).This patch implements the expected behavior, and adds a very specific test case to verify it.
Bye 🙇