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
current
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.
Is
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 process
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 is not
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 intermediate
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 to.
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
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 environment
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/or
On Sat, 3 Apr 2010 12:38:17 +0200
Maciej Mrozowski reave...@gmail.com 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?
--
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
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
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 library
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 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: python
15 matches
Mail list logo
