Jonas Smedegaard 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 archite
* Johannes Schauer , 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.
"hasn't been b
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.
"h
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 H
* Johannes Schauer , 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 package called
n
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
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, othe
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
* Gianfranco Costamagna , 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.
Since the libfoo isn't build o
On 2015-05-25, Gianfranco Costamagna 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 just
be discarded giving poor
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.
11 matches
Mail list logo
