Open davidkna opened 2 years ago
Will investigate this. Linux has been a little tricky and I have not sit down to solve some of the issues. But yea, relying on lsb_release is an issue because if someone doesn't have that package installed on their distro (and as you mentioned, many don't distribute in their 'base'), it leads to garbage results. If we can cut down our external dependencies that we can't control through cargo, it should be avoided at all cost. That is at least my view.
Which is really an issue as os_info is a library and from what I've seen using os_info as a library in comtrya, it can be hard to tease out the issue on a platform is lack of lsb_release as a source of a bug in a caller on os_info.
@martintc
if someone doesn't have that package installed on their distro (and as you mentioned, many don't distribute in their 'base'), it leads to garbage results
There should be no garbage results, because in that case the library falls back to using the release file.
@davidkna
That makes sense, though I prefer conservatively not remove the lsb_release
usage, at least not immediately. Changing the priority should be fine, though.
Many distributions don't seem to distribute
lsb_release
binaries by default, and reading a file should be faster than executing an external binary. In addition,file_release
works better in some situations:lsb_release
detects Fedora WSL remix as Linux, whereasfile_release
picks up Fedora. Now thatfile_release
hopefully works reliably, islsb_release
needed at all?