Hi Josch, Thanks a lot for your suggestions!
The reason why we want different build dependencies (which is indeed what it is) for different versions is that we'd ideally like to support older releases of Debian/Ubuntu from one code base, particularly those which have been released a while ago and are closed to adding now packages now. > - 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. > - 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. Cheers, Nico On Sun, Oct 25, 2015 at 12:12 PM Johannes Schauer <[email protected]> wrote: > Hi Nico, > > Quoting Nico Schlömer (2015-10-24 20:04:19) > > In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) > depend on > > a rather new version of the [Metis]( > https://packages.debian.org/sid/metis) > > package, and that's what's enforced in our debian/control, too. > > I cannot see any (build-)dependency on metis in your debian/control: > > https://bitbucket.org/fathomteam/moab/src/HEAD/debian/control?at=master > > > Now, we would like to provide MOAB for older versions of Debian/Ubuntu as > > well, and for those older distros would drop the optional Metis > dependency. > > Runtime dependency or build dependency? > > > How is this situation best handled? > > The best way to do this is to get your package into Debian. In that case > the > content of debian/control will be different in testing/unstable as well as > in a > backport that you can do for the current stable or oldstable. > > Your problem arises because you want a one-size-fits-all of your upstream > debian/control. Such a one-size-fits-all often doesn't exist but having a > one-size-fits all is also usually not required because the packaging data > including debian/control between different Debian releases can be (and > mostly > is) different. > > If you do not want to get your package into Debian (and through there into > Ubuntu) but instead provide Debian/Ubuntu packages yourself as the upstream > project, I see these options: > > - have one git branch for every Debian/Ubuntu release you want to support > and > let them have different debian/control content depending on what is > required > > - if you were talking about a *runtime* dependency earlier then you could > just > make it a Recommends > > - if you were talking about a *runtime* dependency but need a *strict* > dependency then you can generate this dependency during package build > time > using a substvar (see man deb-substvars) in your Depends line > > - 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 > > - alternatively, if you were talking about a *build* dependency you could > use > build profiles to selectively enable or disable build dependencies > > Note, that all of these suggestions are *not* the right way to do things in > case your package is in Debian or Ubuntu itself. In this case your problem > doesn't arise in the first plae. > > cheers, josch >
