Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Optional dependencies and dependency mess

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Optional dependencies and dependency mess
  • Date: Wed, 24 Mar 2004 11:56:47 -0800

Quoting Arwed von Merkatz <v.merkatz AT gmx.net>:
> We definitely need a way to specify such subdepends in sorcery, i just
> got two prometheus bugs caused by stuff like that. gst-player not
> compiling because gst-plugins wasn't compiled with gconf support and
> straw failing because gnome-python wasn't compiled with gtkhtml support.
> The way i solved this problem with the ruby gnome2 bindings was
> seperating them into many spells, but that only works if the package
> allows it (gst-plugins and gnome-python2 don't easily allow it).
>
> We'll run into this problem quite often, lots of spells already have it,
> so we need an extension of sorcery depends.
> Something like
> depends gst-plugins:gconf,mad
>
> Then cast could check whether gst-plugins was built with those two
> optional_depends on and recompile it otherwise, changing the
> optional_depends for them to yes.
>
> I don't think there's a question whether we need this, we definitely do.
> The behaviour of it is what needs to be discussed, should it
> automatically recompile the stuff, setting the optional_depends to yes?
> One thing about the automatic setting of optional_depends to yes needs
> more work, sorcery shouldn't record those changes in
> /var/state/sorcery/depends unless the user says yes when asked if he
> really wants to cast the spells. Otherwise a user may try a spell, see
> that it wants to recompile something big with changed optional_depends
> and decides against it, but sorcery already recorded the changed
> optional_depends, so the next time the spell is cast it will be
> configured in a way the user didn't want to.
>
> Thoughts? Suggestions?

That sounds like a good solution to me, along with the caveat. ;) I think it
should default to 'n', though, for continuing, otherwise if you do an
unattended update and one of these recompiles is "triggered", it'll
automatically recompile the package without you knowing.

However, this brings up another point: Do we want to have Sorcery defaults be
sane defaults to have everything work and keep going, or default to not change
anything unless specified? What I mean is in the above, would we want Sorcery
to default to 'y' that way unattended casts (and attended ones) have a default
option that would make the new cast work, or do we want Sorcery to default to
not do anything if it would change another package?

-sandalle

--
PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o?
K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++)
tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+
------END GEEK CODE BLOCK------

Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




Archive powered by MHonArc 2.6.24.

Top of Page