Jonas Smedegaard dr at jones.dk writes:
What I do is add a custom build target that rewrites debian/control
based on rmadison query resolving current archs for a given package.
Please don’t forget the debian-ports architectures for this. (I think
this is a point where not-even-on-dpo new
* Gianfranco Costamagna costamagnagianfra...@yahoo.it, 2015-05-25, 07:22:
Problem: I have a package that might depend on a libfoo-dev library.
might because it tries to detect it at configure time, and if the
libfoo is found some features are enabled, otherwise the features are
disabled.
On 2015-05-25, Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote:
I know this might introduce some problems (binNMU?, ABI/API
incompatibilities?)
It will also give 'feature-flip-flop' on the available architectures.
You never know if that library is actually installable, so it would
Hi Debian Developers!
I don't know how much is feasible and useful the field.
Problem: I have a package that might depend on a libfoo-dev
library.
might because it tries to detect it at configure time,
and if the libfoo is found some features are enabled, otherwise
the features are disabled.
Hi,
Quoting Gianfranco Costamagna (2015-05-25 09:22:57)
I don't know how much is feasible and useful the field.
Problem: I have a package that might depend on a libfoo-dev
library.
might because it tries to detect it at configure time,
and if the libfoo is found some features are
Quoting Johannes Schauer (2015-05-25 13:39:13)
Quoting Gianfranco Costamagna (2015-05-25 09:22:57)
Problem: I have a package that might depend on a libfoo-dev library.
might because it tries to detect it at configure time, and if the
libfoo is found some features are enabled, otherwise the
Hi,
Quoting Jonas Smedegaard (2015-05-25 14:34:46)
Both above approaches are suitable only when in control of the dependent
package as well.
why?
cheers, josch
signature.asc
Description: signature
* Johannes Schauer jo...@debian.org, 2015-05-25, 13:39:
http://lists.debian.org/20141217084500.ga16...@alf.mars
In your case this would mean that the source package building
libfoo-dev would modify the binary package libfoo-dev to Provides:
optional-libfoo-dev and additionally build a binary
Quoting Johannes Schauer (2015-05-25 15:43:24)
Hi,
Quoting Jonas Smedegaard (2015-05-25 14:34:46)
Both above approaches are suitable only when in control of the
dependent package as well.
why?
Ah, correction: Only maintainers of dependent package can add a virtual
package (as Helmuth
* Johannes Schauer jo...@debian.org, 2015-05-25, 18:18:
But Helmut's approach only works if libfoo maintainer knows in advance
the list of architectures where libfoo-dev will be built. It can't be
applied if, say, libfoo build-depends on libbar-dev, and libbar-dev
hasn't been built everywhere.
Hi,
Quoting Jakub Wilk (2015-05-25 16:00:39)
But Helmut's approach only works if libfoo maintainer knows in advance
the list of architectures where libfoo-dev will be built. It can't be
applied if, say, libfoo build-depends on libbar-dev, and libbar-dev
hasn't been built everywhere.
11 matches
Mail list logo
