From: Zac Medico <zmedico@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] About how to make compilation think some files are missing
Date: Sat, 12 Feb 2011 15:43:21 -0800 [thread overview]
Message-ID: <4D571B19.3010800@gentoo.org> (raw)
In-Reply-To: <1297525846.6230.40.camel@localhost.localdomain>
On 02/12/2011 07:50 AM, Pacho Ramos wrote:
> This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets
> stabilized, depclean will try to remove glitz, but removing glitz will
> break a lot of apps, needing to rebuild them and, until then, having a
> partially broken system.
>
> I then thought on running revdep-rebuild --library libglitz-glx.so.1
> BEFORE removing glitz (to prevent breakage), but later I remembered it
> wouldn't work as rebuilt packages would link again against
> libglitz-glx.so.1.
>
> Then, my idea would the following:
>
> Would be nice if I could tell portage to make compilation think
> libglitz-glx.so.1 is not present in real system (maybe sandbox could
> prevent its readability inside build environment), and then, I could run
> "revdep-rebuild --library libglitz-glx.so.1" before removing glitz and
> affected apps would not link to it, allowing me to safely remove glitz
> later without having had a broken system at any time.
>
> What do you think? Thanks
Ideally, the build system(s) involved would have options to explicitly
disable linking against the deprecated library.
Barring that possibility, something like your sandbox idea seems like
the second-best solution.
On par with the the sandbox idea would be to migrate the deprecated
library to a directory which is not included in the default library
search path, and to use a global LD_LIBRARY_PATH setting so that your
apps can find it until they are rebuilt. Then you could execute your
rebuilds in an environment with a modified LD_LIBRARY_PATH value that
excludes the path of the deprecated library.
--
Thanks,
Zac
next prev parent reply other threads:[~2011-02-13 0:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-12 15:50 [gentoo-portage-dev] About how to make compilation think some files are missing Pacho Ramos
2011-02-12 17:22 ` Martin Doucha
2011-02-12 18:57 ` Pacho Ramos
2011-02-12 23:43 ` Zac Medico [this message]
2011-02-13 11:54 ` Pacho Ramos
-- strict thread matches above, loose matches on Subject: below --
2011-02-12 16:06 Pacho Ramos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D571B19.3010800@gentoo.org \
--to=zmedico@gentoo.org \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox