sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
Re: [SM-Sorcery] wget .so dependencies (possibly global problem)
- From: Ondra Tomecka <otom7630 AT lucy.troja.mff.cuni.cz>
- To: SourceMage Sorcery List <sm-sorcery AT lists.ibiblio.org>
- Subject: Re: [SM-Sorcery] wget .so dependencies (possibly global problem)
- Date: Wed, 4 Feb 2004 14:55:49 +0100 (CET)
cast --fix would detect this problem, but somehow I don't think we should
expect users to do cast --fix after every upgrade. The possibility that
upgrade of some spell would break lots of spells at once, or even only one
but important, seems very bad for me. I think there should be some
solution in sorcery for this. If this happens to something like 'make', it
can possibly cause all the hell break loose.
I'm still thinking about leaving older versions in place ;-)
Some ideas (so I won't forget them when I'll have to implement it ;-) ):
- check if build directory contains lib*.so.* files to know if we need to
check for major version number upgrade at all
- for those libs, check if they were installed in previous version (to
exclude files used internally while building the spell), and check if
previous version has different major version number
- make sure cache for previous version exists before dispeling it,
if it doesn't exist, create it
- after installing new version, get older library version from cache
- warn user that he has currently more versions of certain library, and
suggest to recompile all spells which are currently using the old
version. This message should be displayed at the end of cast command,
after list of successes/failures, to make sure user sees it. It would
be good to have switch for cast to recast spells which are using certain
library, like "cast --upgrade-library libintl.so.2"
Doh, looks like awful lot of work :(
However, I think it would be worth it.
Andy
On Wed, 4 Feb 2004, Arwed von Merkatz wrote:
> On Wed, Feb 04, 2004 at 08:14:24AM -0500, Paul wrote:
> > Did cast --fix detect the problem?
>
> It did detect and fix it fine on my system for wget and fetchmail, which
> were the only ones affected by this.
> It seems to be a bit different on some systems, e.g. on IRC someone had
> the problem that 'make' was linked to libintl, so the recast failed.
>
> > On Wed, 2004-02-04 at 08:08, Robin Cook wrote:
> > > I have had this problem on 4 different machines so far. On everyone on
> > > of them just recasting wget fixed the problem (of course it wasn't
> > > trying to upgrade wget either.)
> > >
> > > CuZnDragon
> > > Robin Cook
> > >
> > > On Wed, 2004-02-04 at 07:06, Paul wrote:
> > > > cast --fix is supposed to detect and fix these problems. Most spells
> > > > aren't as problematic as wget, since if --fix finds a problem with
> > > > wget,
> > > > it can't very well d/l sources to recompile can it ;)
> > > >
> > > > Anyhow, when I upgraded gettext, I didn't have any errors. Another
> > > > person on IRC did. I've no idea why... however I did write a little
> > > > tool
> > > > that would check all binaries and libs installed by a spell and make
> > > > sure that all the libs needed are provided by a spell that it depends
> > > > on. afraydknot has it and will likely be integrating it with his
> > > > prometheus work.
> > > >
> > > > On Wed, 2004-02-04 at 07:00, Ondra Tomecka wrote:
> > > > > Hi all,
> > > > >
> > > > > I just updated few spells, gettext as one of them. Gettext updated
> > > > > library
> > > > > libintl.so from libintl.so.2 to libintl.so.3. I would not expect
> > > > > this to
> > > > > cause any problems, as file libintl.so still exists and correctly
> > > > > points
> > > > > to new version. However, I tried to summon some other spell, and
> > > > > wget
> > > > > failed with message that it cannot find libintl.so.2 (which it
> > > > > cannot
> > > > > becase it's not there anymore).
> > > > >
> > > > > I made a little research with ldd to find out that there are lot of
> > > > > spells
> > > > > which expect exact major version of library (which is
> > > > > understandable as
> > > > > change in major version usually means ABI change), but this means
> > > > > that
> > > > > upgrade of major version of shared library can break lots of
> > > > > programs at
> > > > > once if it deletes previous version.
> > > > >
> > > > > One possible solution for this can be to recompile all spells which
> > > > > use
> > > > > the upgraded library, but I'm afraid that this could possibly be
> > > > > terribly
> > > > > time-consuming.
> > > > >
> > > > > Another possibility would be to leave previous version available,
> > > > > and add
> > > > > it to list of files of the spell which installs new version, so it
> > > > > would
> > > > > still be tracked by sorcery. And possibly check if existing older
> > > > > versions
> > > > > are still being used by some spell, which would be probably very
> > > > > slow too.
> > > > > Or add sorcery subcommand to check for unused older versions and
> > > > > remove
> > > > > them ;-)
> > > > >
> > > > > The more I think about it, the more I like the latter option with
> > > > > added
> > > > > subcommand to sorcery. Only bad thing about it is a lot of work
> > > > > which it
> > > > > would require...
> > > > >
> > > > >
> > > > > Any thoughts about this?
> > > > >
> > > > > Andy
> > >
> > > _______________________________________________
> > > SM-Sorcery mailing list
> > > SM-Sorcery AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
> > --
> > De mortuis nihil nisi bonum.
> >
>
>
>
> > _______________________________________________
> > SM-Sorcery mailing list
> > SM-Sorcery AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
>
>
>
-
[SM-Sorcery] wget .so dependencies (possibly global problem),
Ondra Tomecka, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Paul, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Robin Cook, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Paul, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Arwed von Merkatz, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Ondra Tomecka, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Paul, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Ladislav Hagara, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Jeremy Kolb, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Arwed von Merkatz, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Ondra Tomecka, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Paul, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Ondra Tomecka, 02/04/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Eric Schabell, 02/05/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Jeremy Kolb, 02/05/2004
- Re: [SM-Sorcery] wget .so dependencies (possibly global problem), Andrew, 02/05/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Ondra Tomecka, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Arwed von Merkatz, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Paul, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Robin Cook, 02/04/2004
-
Re: [SM-Sorcery] wget .so dependencies (possibly global problem),
Paul, 02/04/2004
Archive powered by MHonArc 2.6.24.