Hi Nico, Quoting Nico Schlömer (2015-10-26 00:47:54) > particularly those which have been released a while ago and are closed > to adding now packages now. packages can be added via backports. > > - if you were talking about a *build* dependency, then you can generate > these > > before building by having a debian/control.in and turning that into the > > right debian/control depending on what you want to build > > Good idea. I'll look into it. remember that the other way I mentioned, having different git branches for different target distributions would also apply for your use case. > > - alternatively, if you were talking about a *build* dependency you > could use > > build profiles to selectively enable or disable build dependencies > > Never heard of it. I'll check it out as well. This would work technically but there is no accepted way to do this in practice yet in Debian or Ubuntu. Build profiles allow you to select or unselect build dependencies depending on conditions you specify in the Build-Depends line. So technically it would be possible to say that a build dependency should only be used if the profiles "debian" and "unstable" are active and then when you build your source package you would have to take care to have the right profiles active per build with the DEB_BUILD_PROFILES environment variable or with the -P option to dpkg-buildpackage. There is more info on https://wiki.debian.org/BuildProfileSpec But remember that at this point this would just be another hack! While build profiles can be used this way to support multiple distributions and releases with a single debian/control file, there is not yet any decision (or even the attempt to have it) of how the build profiles should be named for this use case. cheers, josch
Attachment:
signature.asc
Description: signature