I’ve just added the GLFW3 PPA to the dependency list for the GNU Radio PPA, in an effort to build packages of gr-fosphor for Trusty. Not sure if this, or attempting to provide a backport of the official libglfw3-dev package, would be the best option?
In any case, just wanted to mention this in case it could affect building packages of anything else.
If there are already recent versions of libglfw3-dev available on the GLFW3 PPA, then its probably preferable to add it as a PPA dependency. I don’t think it will hurt anything, and that sounds like less work than back-porting.
The only concern with back porting is that sometimes new packages conflict with stock ubuntu release ones and then its harder to use the gnuradio ppa. It depends how obscure the package is and how much other packages depended on. In general, I dont think its a problem.
Thanks for the advice.
To build gr-fosphor I grabbed the package source from the upcoming Ubuntu 16.04 release — which in turn has come in via Debian Sid — and just updated the versions of dependencies specified in the debian/control file.
Bearing in mind what you said backporting packages, if we want this in our PPA, I’m not sure whether I should:
Going with (3) and since gr-fosphor does not appear to have tagged releases, would the version be after the GNU Radio version plus git commit? E.g. 3.7.9-3.e1eb11b-myriadrf1 ?
Bearing in mind what you said backporting packages, if we want this in our PPA, I’m not sure whether I should:
My only real caution was including a dependency package in the PPA that was going to break some core ubuntu library. Backporting for the latest gnuradio out of tree packages is specifically the right kind of thing for this PPA. And if the build requires a external package thats in a separate PPA like GLFW3 PPA, then there definitely wont be a problem.
Now someone who wants to use myriadrf gnuradio gr-fosphor has to also add the GLFW3 PPA, and that could cause some breaking package replacement… that’s unfortunate, but its more of an edge case. And what else can you do? In general, we are talking about development versions of these new packages that causes incompatible situations, so it really is more of an edge case. If someone is developing something with this GLFW3 library, and wants to use the native ubuntu dev version, they might have to just not use this particular PPA… 
So if all of the dependencies for the gr-fosphor can be met either by the gnuradio PPA or by adding dependencies to the PPA, then “backportpackage” may be the easiest way to handle this. Its a single command which will download ubuntu 16.04 version of the source package and submit it for build for the specified version: https://opensourcehacker.com/2013/03/20/how-to-backport-packages-on-ubuntu-linux/#Running_backportpackage_command
If the backportpackage command doesnt work (which usually means there is a dependency name change). Then I would download the ubuntu 16.04 version and modify the control and changelog to make it work and try to upload that.
Going with (3) and since gr-fosphor does not appear to have tagged
releases, would the version be after the GNU Radio version plus git
commit? E.g. 3.7.9-3.e1eb11b-myriadrf1 ?
If thats what Ubuntu 16.04 was already using for a naming convention. I have seen some other packages like that too. Its probably fine.