You have attached a patch, for the "how?", but "why?" isn't answered as
far as I'm concerned; so why would that be useful?
It would be useful to be able to compile an application (in my case wine) that needs both gnutls and cups with latest packages, and not legacy ones.
The story behind that is, I'm trying to have every -dev
packages wine depends on multi-arch capable, but, as my time is short,
I'd like to focus only on latest version of packages to be able to push upstream (if needed) more easily and not duplicate effort on legacy packages. Maintainers are also certainly more inclined to update current stable packages than legacy ones.
Wine (trunk at least) can build against libgnutls28-dev, but also depends on libcups2-dev so I'm forced to use libgnutls-dev instead.
For the record, libgnutls28-dev
can be marked multi-arch: same immediately (see bug 678070, reported
against libgnutls-dev at that time, but applies to libgnutls28-dev - I
should update/duplicate this bug), cups (bug 689084), in the other hand, needs more
efforts (affected by bug 688958, also needs to migrate to pkg-config so we
can have an arch independent cups-config script), but it seems feasible.
A perhaps better option could be to directly build-depends on libgnutls28-dev (if no other packages depends on cups and legacy gnutls).