Public SourceMage Discussion List

[Remko van der Vossen <wich AT yuugen.jp>]

On Fri, Aug 29, 2014 at 09:51:39AM +0200, Thomas Orgis wrote:
> 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.

As far as I know there is no (existing) way to force a certain casting
order in sorcery, the best we can do is improve our DEPENDS files so
that we get a more complete dependency tree. That still leaves problems
with cyclic dependencies though, which we need to break as much as
possible. Automatic cycle breaking in sorcery by first installing
without optional dependencies and later with would be nice, but I don't
see it happening anytime soon. (Also you'd have to take into account sub
dependencies, so you might even get more than two rounds for some
spells.)

In lieu of complete DEPENDS files and some mechanism to recast dependers
on ABI incompatible spell casts we can work with UP_TRIGGERS to get all
dependers cast. There is no need to create lists of spells in
UP_TRIGGERS, it's just a lot of work, and is liable to be incomplete.
It's much better to use a bit of automated depender discovery like is
done in libpng/UP_TRIGGERS of the devel/libpng branch (not the
devel/libpng-1.6 branch.)

> 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?)

It isn't just messy, it can cause major security headaches. You'd have
to continually monitor security issues in the whole history of spells,
and support a way to get rid of installed libraries that have security
issues. Which of course brings us right back to the original problem as
you then also have to make sure to recast any dependers which is where
the whole problem began...

> 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.

I would much rather we invest time in making sure that we recast the
right stuff upon ABI incompatible changes in the right way, which means;
1) actively rolling out as-needed
2) starting work on getting better quality DEPENDS files
3) creating some mechanism in sorcery which allows us to recast
   dependers upon ABI incompatible changes
4) creating a mechanism in sorcery to automatically break dependency
   cycles

We can start working on 1) right now, 2) and 3) can be partially worked
around using smart UP_TRIGGERS scripts. We'll have work in the long run
for 2), 3) and 4). Note that in this case it also becomes easy when to
remove any special UP_TRIGGERS scripts; when 2) and 3) are done.

Regards, Remko