On Wed, Feb 22, 2017 at 08:51:10AM +0000, Jonathan Dowland wrote: > On Tue, Feb 21, 2017 at 07:51:20AM -0500, Greg Wooledge wrote: > > No, stop. The second step if there is not already a backport is to try > > to backport it yourself. Maybe ask judd in IRC first, whether a backport > > is believed to be *possible*. Sometimes the bot is wrong, but it's a > > starting point. If judd thinks all the dependencies are satisfiable, > > then you can try the backport. > > judd sounds like a useful system, but I disagree that the next step is > necessarily backports. For example, I just recently installed sid's "flatpak" > on a stretch system, and all dependencies were satisfyable from stretch (in > fact, were already installed, from when I installed the version of flatpak in > stretch). So sometimes this is a quick solution. > > If the version in sid had wanted to pull in dependencies from sid, then I > would > have had to make a judgement call as to the impact of that, versus the > inconvenience of building from source. > > > If a backport isn't possible, I would actually prefer to build the package > > normally from upstream source code (./configure; make; sudo make install) > > than to install a binary from testing/unstable onto stable. > > Yes, I think that might actually be easier than wrangling with Debian > packaging, especially if the user is not already familiar with it. >
The only thing I'd add here is that in this case, I'd create a dummy Debian package with no contents but an appropriate version number and dependencies, and install it, so the system knows it is there and the dependent libraries are depended on. This way when upgrades happen APT will tell you if there is going to be a problem upgrading the libraries instead of just doing it and breaking the package you built from source. Mark
