Closed hmaarrfk closed 4 years ago
Yes, I've noticed the same thing on Ubuntu 19.04.
As it is, this package should not be used on these platforms.
Would packaging libudev
be a solution?
depends on how much of the kernel it depends on right. we can try. But not sure.
I think libudev got moved into systemd, we would have to think about how to integrate systemd into conda forge.
I think libudev got moved into systemd, we would have to think about how to integrate systemd into conda forge.
I don't know if that makes much sense to be honest.
right, honestly, on my laptop i just simlinked libudev.so.0 and libudev.so.1, but i know that is bad....
Does this help?
For ubuntu 14.04 and above
The easiest method I found was to just download the .deb (direct link to 64-bit download and to 32-bit download) and double click it to install it or use dpkg to install it:
dpkg -i libudev0_175-0ubuntu9_amd64.deb
See also https://unix.stackexchange.com/questions/156776/arch-ubuntu-so-whats-the-deal-with-libudev-so-0
Says there,
It's possible to build an older version of
libudev
that still provides.so.0
if it's necessary.
Maybe that's what we should focus on?
But would it work if I use a libudev.so.0
on the newest Ubuntu?
I don't know; the SO answer seems to imply that it should work!
I think it does work, my fear is that it is a little complicated to install.
This might also be the first of many issues regarding low level access to hardware with conda-forge that will pop up.
My Ubuntu 18.04 builds seem to fail with
I think it is because ubuntu uses
libudev1
and we have compiled withlibudev0