Hi Richard,
Sorry, my Python knowledge is quite basic. I'm sure it's possible to
have a (global?) EXCLUDE_FROM_SHLIBS list holding subpackage names, but
how it could lead to performance improvement? It would also need some
check for every subpackage.
Could you please give more details?
And
On Mon, 2016-10-10 at 20:02 +0300, Andrii Bordunov wrote:
> Some packages containing shared libraries might be registered
> as shlib providers when they shouldn't (for example, the lib is for
> their private use and must not generate any dependency).
>
> EXCLUDE_FROM_SHLIBS is targeted at that,
On 15 November 2016 at 15:05, Andrii Bordunov wrote:
> Ping-2. Guys? Anything?
>
Sorry, missed this. It looks reasonable and doesn't introduce any changes
to existing packaging, so it's in my queue now.
Ross
--
___
Ping-2. Guys? Anything?
Thank you,
Andrii
On 19.10.16 16:58, Andrii Bordunov wrote:
Ping? Any comments?
Thank you,
Andrii
On 10.10.16 20:02, Andrii Bordunov wrote:
Some packages containing shared libraries might be registered
as shlib providers when they shouldn't (for example, the lib
Ping? Any comments?
Thank you,
Andrii
On 10.10.16 20:02, Andrii Bordunov wrote:
Some packages containing shared libraries might be registered
as shlib providers when they shouldn't (for example, the lib is for
their private use and must not generate any dependency).
EXCLUDE_FROM_SHLIBS is
Some packages containing shared libraries might be registered
as shlib providers when they shouldn't (for example, the lib is for
their private use and must not generate any dependency).
EXCLUDE_FROM_SHLIBS is targeted at that, but it could be set
for entire recipe only.
This patch expands