That would work and since it would not change an existing package, it
might pass the SRU rules.
Personally I do not want to work on glfw2 - it's now been about 3.5
years since it went EOL and I think applications should move to glfw3.
However if you can find another Ubuntu developer (which btw I
The one possible solution, though I don't know if it is worth the effort
and if it is compatible with Ubuntu policy, would be to create a
separate libglfw2-dev package, which would be almost identical to
libglfw-dev, but would install libglfw2.so link to libglfw.so.2 (and
appropriate changes for
Yes the change would only affect compiling applications, but I still
think it's too invasive for an SRU.
> That could mean breaking compilation of some packages... but I don't
think any package depends on GLFW.
These are the reverse dependencies in xenial:
$ reverse-depends -r xenial src:glfw
> I know people are using LTS, but the only thing I can think of is
renaming libglfw.so for one of the packages - a change which is far to
invasive for a Xenial SRU (as it would break applications already
relying on the libglfw.so name).
Actually this would only affect *compiling* applications,
> James, are you sure that /usr/lib/x86_64-linux-gnu/libglfw.so comes
from libglfw-dev package?
Yes. Here is the conflict:
$ dpkg-deb -c libglfw3-dev_3.1.2-3_amd64.deb | grep libglfw.so
lrwxrwxrwx root/root 0 2016-01-29 05:17
./usr/lib/x86_64-linux-gnu/libglfw.so -> libglfw.so.3
$
James, are you sure that /usr/lib/x86_64-linux-gnu/libglfw.so comes from
libglfw-dev package?
First, the libglfw-dev should have only include files (and maybe static
library), plus documentation. Doesn't the library come from libglfw2?
Second, the package should include fully qualified
There is a file conflict:
/usr/lib/x86_64-linux-gnu/libglfw.so
However this is a fairly academic question now since GLFW 2 no longer
exists in yakkety and I expect attempting to fix this in Xenial would be
too much for an SRU.
If you have an idea on how to fix this, I'd happily listen to it
