On Thu, Jul 15, 2010 at 07:28:40PM +0200, Markus Hauschild wrote:
> On Thu, Jul 15, 2010 at 10:49 AM, Mike Auty wrote:
> > Ideally, these calls should either adhere to FEATURES="-preserve-libs",
> > or there should be a tool that can identify which files portage has
> > preserved, and allow easy r
On Thu, Jul 15, 2010 at 10:49 AM, Mike Auty wrote:
> Ideally, these calls should either adhere to FEATURES="-preserve-libs",
> or there should be a tool that can identify which files portage has
> preserved, and allow easy rebuilding of dependent packages, and removal.
> At the moment, I'm having
Le jeudi 15 juillet 2010 à 09:49 +0100, Mike Auty a écrit :
[...]
> I can live with this for in places where it causes massive breakage
> (openssl/libpng/libjpg), because it's genuinely useful, but I think it
> should be restricted to such important packages, or at least disabled by
> FEATURES="-pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry I'm a bit late to the thread,
Just to add that empathy preserves libemapthy in this manner too.
On 05/07/10 17:40, Gilles Dartiguelongue wrote:
>
> 1. How is it different than preserved-libs feature from
> portage-2.2 ? The issue
Le vendredi 02 juillet 2010 à 08:51 +0300, Samuli Suominen a écrit :
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_
On Friday, July 02, 2010 01:51:25 Samuli Suominen wrote:
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=3
On 07/02/2010 09:03 AM, Samuli Suominen wrote:
> On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
>> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>>> It's a hack, not a solution
>>
>> Should we make repoman issue a warning about it?
>>
>> It already warns about using make -j1 as a workaround for ups
On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>> It's a hack, not a solution
>
> Should we make repoman issue a warning about it?
>
> It already warns about using make -j1 as a workaround for upstream
> issues. The new warning could be on the same
On 07/02/2010 08:51 AM, Samuli Suominen wrote:
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
>
On 7/2/10 7:51 AM, Samuli Suominen wrote:
> It's a hack, not a solution
Should we make repoman issue a warning about it?
It already warns about using make -j1 as a workaround for upstream
issues. The new warning could be on the same level (yellow, not red).
Paweł
signature.asc
Description: Op
I've recently stumbled upon several packages unnecessarily using old
preserve_old_lib feature from eutils.eclass, namely:
libgnomekbd
libproxy
And then users hit issues like this:
https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
Please only use the preserve_old_lib function in case of breaking
11 matches
Mail list logo