* [gentoo-portage-dev] About how to make compilation think some files are missing
@ 2011-02-12 15:50 Pacho Ramos
2011-02-12 17:22 ` Martin Doucha
2011-02-12 23:43 ` Zac Medico
0 siblings, 2 replies; 6+ messages in thread
From: Pacho Ramos @ 2011-02-12 15:50 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* [gentoo-portage-dev] About how to make compilation think some files are missing
@ 2011-02-12 16:06 Pacho Ramos
0 siblings, 0 replies; 6+ messages in thread
From: Pacho Ramos @ 2011-02-12 16:06 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-portage-dev] About how to make compilation think some files are missing
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
1 sibling, 1 reply; 6+ messages in thread
From: Martin Doucha @ 2011-02-12 17:22 UTC (permalink / raw
To: gentoo-portage-dev
Dne 12.2.2011 16:50, Pacho Ramos napsal(a):
> 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
I think you want to update to portage-2.2 (you need to unmask it
manually). It does exactly what you want in this case.
Regards,
Martin Doucha
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-portage-dev] About how to make compilation think some files are missing
2011-02-12 17:22 ` Martin Doucha
@ 2011-02-12 18:57 ` Pacho Ramos
0 siblings, 0 replies; 6+ messages in thread
From: Pacho Ramos @ 2011-02-12 18:57 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
El sáb, 12-02-2011 a las 18:22 +0100, Martin Doucha escribió:
> Dne 12.2.2011 16:50, Pacho Ramos napsal(a):
> > 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
>
> I think you want to update to portage-2.2 (you need to unmask it
> manually). It does exactly what you want in this case.
>
> Regards,
> Martin Doucha
>
>
I am not sure if portage-2.2 would also cover this case: in this
example, the problem appears because of people uninstalling
*intentionally* media-libs/glitz (as it's no longer needed)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-portage-dev] About how to make compilation think some files are missing
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 23:43 ` Zac Medico
2011-02-13 11:54 ` Pacho Ramos
1 sibling, 1 reply; 6+ messages in thread
From: Zac Medico @ 2011-02-12 23:43 UTC (permalink / raw
To: gentoo-portage-dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [gentoo-portage-dev] About how to make compilation think some files are missing
2011-02-12 23:43 ` Zac Medico
@ 2011-02-13 11:54 ` Pacho Ramos
0 siblings, 0 replies; 6+ messages in thread
From: Pacho Ramos @ 2011-02-13 11:54 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
El sáb, 12-02-2011 a las 15:43 -0800, Zac Medico escribió:
> 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.
Didn't think about that last LD_LIBRARY_PATH option, looks easier for
now. Thanks
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-13 12:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2011-02-13 11:54 ` Pacho Ramos
-- strict thread matches above, loose matches on Subject: below --
2011-02-12 16:06 Pacho Ramos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox