sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Thomas Orgis <thomas-forum AT orgis.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] devel-xorg-modular merging
- Date: Fri, 29 Aug 2014 09:51:39 +0200
Am Wed, 27 Aug 2014 23:03:36 -0400
schrieb Sukneet Basuta <sukneet AT gmail.com>:
> I've attached what I posted close to a year ago. Javier also had the idea
> of chaining a planar list of casts, which maybe a better solution than
> trying to rely on UP_TRIGGERS.
Well, the list seems about right. The ones I encountered are in there
(cairo and pango stuff).
What I wondered, though: Couldn't we just keep the
libpthread-stubs.so.0 in place somehow? I mean ... it's a bit stupid to
actively break stuff by removing this (stupid) library. What we
actually want is the new pthread-stubs pkgconfig file and, some
insurance that no future cast will link to this lib. Isn't that
possible? We could provide an updated libpthread-stubs 0.2 spell that
only installs the binary lib needed by already installed spells. The
0.3 libpthread-stubs would be a new spell that installs the normal
stuff and would not conflict with the current version of
libpthread-stubs as it doesn't install the .so.
This is messy in its own right, but this kind of mess would at least
avoid breaking any installed spell. We could hide the mess by actually
building the 0.2 .so inside the 0.3 spell and install it as if it would
belong (removing the plain .so to avoid fresh linking ... or do I
misremember linker behaviour?)
The question would be when to remove the .so for good, but I wouldn't
be in such a hurry. We'd need the same decision on when to remove these
triggers.
Alrighty then,
Thomas
PS: Perhaps you noticed, I am trying to revive
http://sourcemage.org/issues/423 by posting there. We might shift some
discussion there, at least conclusions.
Attachment:
signature.asc
Description: PGP signature
-
[SM-Discuss] devel-xorg-modular merging,
Thomas Orgis, 08/24/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Sukneet Basuta, 08/26/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Thomas Orgis, 08/26/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Sukneet Basuta, 08/26/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Thomas Orgis, 08/27/2014
- Re: [SM-Discuss] devel-xorg-modular merging, Florian Franzmann, 08/27/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Thomas Orgis, 08/27/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Sukneet Basuta, 08/26/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Thomas Orgis, 08/26/2014
- <Possible follow-up(s)>
-
Re: [SM-Discuss] devel-xorg-modular merging,
Sukneet Basuta, 08/27/2014
- Re: [SM-Discuss] devel-xorg-modular merging, Thomas Orgis, 08/29/2014
-
Re: [SM-Discuss] devel-xorg-modular merging,
Sukneet Basuta, 08/26/2014
Archive powered by MHonArc 2.6.24.