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