On Mon, Apr 05, 2010 at 03:27:34PM +0200, Tiziano MMMller wrote:
> > Via that, the resolver can see that a rebuild is necessary and plan a
> > rebuild of all consumers (whether NEEDED based or revdep). Note
> > preserve-lib would be rather useful here- specifically holding onto
> > the intermed
Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski:
> On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote:
>
> >> Besides I
> >> can already imagine PMS-related discussion regarding "make the PMs check
> for rdeps per default before unmerging things" - thx but no thx.
> > This
Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring:
> On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote:
> > Unconditionally removing libraries (instead of preserving them) and making
> > their reverse runtime dependencies reinstalled is unacceptable because
> > "emerge"
On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote:
> Unconditionally removing libraries (instead of preserving them) and making
> their reverse runtime dependencies reinstalled is unacceptable because
> "emerge" process involving multiple packages is not atomic. Simple as that.
> I
On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote:
>> Besides I
>> can already imagine PMS-related discussion regarding "make the PMs check
for rdeps per default before unmerging things" - thx but no thx.
> This is not related to PMS. Paludis for example does it already with the
> curren
Am Samstag, den 03.04.2010, 23:05 +0200 schrieb Maciej Mrozowski:
> On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote:
> > Shouldn't we fix that buildsystem then? Do you have an example of a
> > package/buildsystem that does that?
> "We" already do, the thing is that maybe we don't have t
On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote:
> Shouldn't we fix that buildsystem then? Do you have an example of a
> package/buildsystem that does that?
"We" already do, the thing is that maybe we don't have to.
https://bugs.gentoo.org/show_bug.cgi?id=240323
From top of my head: pyt
Am Samstag, den 03.04.2010, 12:38 +0200 schrieb Maciej Mrozowski:
> Problem
>
> ..is known, let me summarize briefly.
>
> Uninstalling packages providing libraries, without checking reverse runtime
> dependencies of those packages leaves their dependencies unsatisfied
> (packages
> with broken
On 03-04-2010 14:09:42 +0200, Maciej Mrozowski wrote:
> > because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should
> > (in theory and on some platforms at least) fail.
>
> It doesn't matter, as 'broken' build system may alphabetically find
> library by file name, and link to this lib
On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote:
> Is it known why this does happen exactly? When a lib is kept because it
> is still used, only its soname + what the soname points to should be
> kept. That would mean the lib can no longer be found during linking,
> unless you add some
Le samedi 03 avril 2010 à 12:38 +0200, Maciej Mrozowski a écrit :
> There is opt-out suggestion[2], unfortunately it does not provide any info
> how
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned,
> maybe - as Brian Harring suggested - sandbox could be used to som
On Sat, 3 Apr 2010 12:38:17 +0200
Maciej Mrozowski wrote:
> 2. During "emerge", unset environment variable corresponding to said
> preserved library directory - orphans are no longer located.
Wouldn't that cause failure when the toolkit relies on a 'hidden'
preserved library?
--
Best regards,
On 03-04-2010 12:38:17 +0200, Maciej Mrozowski wrote:
> Problem
>
> ..is known, let me summarize briefly.
>
> Uninstalling packages providing libraries, without checking reverse
> runtime dependencies of those packages leaves their dependencies
> unsatisfied (packages with broken executables and/
On Sat, Apr 03, 2010 at 12:38:17PM +0200, Maciej Mrozowski wrote:
> exactly it's supposed to be achieved. As far as portage/pkgcore is concerned,
> maybe - as Brian Harring suggested - sandbox could be used to somehow "hide"
> preserved libraries or preserved library directory from ebuild environ
Problem
..is known, let me summarize briefly.
Uninstalling packages providing libraries, without checking reverse runtime
dependencies of those packages leaves their dependencies unsatisfied (packages
with broken executables and/or shared libs).
Some package managers try their best not to remov
15 matches
Mail list logo