Skip to Content.
Sympa Menu

sm-sorcery - RE: [SM-Grimoire]Re: [SM-Sorcery][Fwd: xfree86 as a special case]

sm-sorcery AT lists.ibiblio.org

Subject: Discussion of Sorcery related topics

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: Reapl Paratorn <reapl AT reapl.net>
  • Cc: sm-sorcery AT lists.ibiblio.org
  • Subject: RE: [SM-Grimoire]Re: [SM-Sorcery][Fwd: xfree86 as a special case]
  • Date: 21 Oct 2002 22:00:02 -0400

<removed cross posting to sm-grimoire>




On Mon, 2002-10-21 at 20:35, Reapl Paratorn wrote:
> I know that I have missed the discusison on this and am coming in late, but
> there are cases where the suggested single dependancy graph files, and that
> is changing dependancies.
>
> Now this isnt an issue with just X apps but everything.
It is a particular issue with X because it was felt that including X as
a depends of all X apps was a little redundant.

>
> If you don't have all spells aware of their own COMPLETE dependancy needs
> then on major changes to applications can break spells really easy that
> might not be understood and noticed. The idea of one spell knowing who it
> depends on, and then in turn who all they depend on, up a tree is actually
> the problem.
Generaly this is done, excluding the base system. It's assumed that the
base system is needed for everything and is always there.

>
> What happens when something in the tree, changes its own dependancies, and
> removes something that the leaf application actually needs for it's own
> requirements? The only way to deal with this without full dependancies is to
> actually manually recheck the dependancies of every spell that depends on
> the middle layer spell. Now issues are that unless you remove the speel that
> the middle layer spell removed its dependancy on, then you wont even notice
> that the leaf spell should be broken.
>
> so IF ProgA depends on ProgB, but
> ProgA also depends directly on ProgZ
> but ProgB depends on ProgZ for version blah
>
> new version of ProgB released without dependancy on ProgZ
> now if ProgZ isnt removed from system, ProgA will still be fine, but
> if it
> is then it will fail.
>
> The best way to deal with this is to actually stop a cast from doing multple
> casts of the same spell on any one single invocation. Then you make ProgA
> and ProgB both depend on ProgZ, and if the change above occurs, then ProgZ
> will still be there due to ProgA's dependancy and nothing breaks.
Done.

>
> Now this makes the logic in cast need to be such that it can parse through a
> list of spells, check for multiples and only cast them once. I would love
> cast to do this, I always seem to get annoyed seeing some spell cast
> multiple times on updates or major changes on new systems.
Done.
libdepends and parts of cast have been rewritten in the last month.

>
> Now if ppl have already got some other way around this problem that I havent
> seen as haven't read ALL the mail from the last week, then great. If you
> haven't and you think this stuff doesn't happen often enough to bother, then
> I wold ask you to please think again. I worked in the field of Software
> Management Systems and have seen this kind of update breaking things issue
> quite a number of times.
I don't think anyone would say that dependency checking is trivial or
unimportant ;) Least of all me since I rewrote the stuff (Yes, I'm the
one to blame for any cast errors you get).
One other piece we need to get in is dependency checking for dispelling,
which currently does not exist.

>
> Anyway.....keep up the great efforts ppl
>
> Reapl
>
> -----Original Message-----
> From: sm-sorcery-admin AT lists.ibiblio.org
> [mailto:sm-sorcery-admin AT lists.ibiblio.org]On Behalf Of Andrew
> Sent: Tuesday, 22 October 2002 9:45 AM
> To: sm-sorcery AT lists.ibiblio.org; sm-grimoire AT lists.ibiblio.org
> Subject: Re: [SM-Grimoire]Re: [SM-Sorcery][Fwd: xfree86 as a special
> case]
>
>
> that sounds like a job for
> optional_depends
> right?
>
> for example MPlayer has integration with gnome (i think), but its an
> optional dependancy. so it works anyways.
>
> On Mon, Oct 21, 2002 at 04:51:36PM -0700, Nick Jennings wrote:
> > Yes, I understand the chain of dependencies, and why not every spell
> > needs to depend on X if they are an X app. The problem lies in when
> > some user doesn't want to use a window manager, but want's to compile
> > an X app.
> >
> > You don't need GNOME or KDE (or any other window manager) to compile
> > xclock, or even xmms (i think)... What about this instances?
> >
> >
> > On Mon, Oct 21, 2002 at 03:30:49PM -0700, Andrew wrote:
> > > On Mon, Oct 21, 2002 at 02:40:58PM -0700, Seth Woolley wrote:
> > > > I thought it was "eventual" dependency. If you depended on gnome, for
> > > > example, gnome already depends on xfree86, so you don't need to dupe
> it,
> > > > because if X isn't cast, it will get cast anyways as gnome can't be
> > > > installed without X.
> > > >
> > > i think thats what we decided on in the meeting, if a spell A depends
> > > on B, and B depends on Xfree86, then you dont need to list xfree86 as
> > > a dependancy of A, but if no such dependancy exists, then you need to
> > > list xfree86 as a dependancy. If we look at dependancies like a directed
> > > graph, there must always be some path from any spell that uses X to X,
> > > regardless of the length of the path.
> > >
> > > as a more concrete example:
> > > unixcw (morse code tutor), depends on qt-x11
> > > and
> > > qt-x11 depends on xfree86
> > > therefore i dont need to change anything with unixcw because it has
> > > xfree86 as an inherited dependancy.
> > >
> > > as what i think my constitute an error:
> > > xscorch depends on gtk+
> > > gtk+ depends on glib
> > > glib depends on nothing
> > > i was not aware that one could play xscorch, or use gtk+ without X.
> > > i think this goes by unnoticed because nobody casts gtk+ from a brand
> > > new SM box without casting xfree86 first. glib probably should depend
> > > on xfree86.
> > >
> > > one more example ;)
> > > dcgui depends on xfree86 and qt-x11
> > > and of course qt-x11 depends on xfree86
> > > nothing is 'wrong' with this but the extra dependancy is uneccesary
> > >
> > > im sure we all knew this already, but just to make it crystal clear.
> > >
> > > on the case of glibc and gcc, i believe we dont need to worry since they
> > > are part of the base system, and everything depends on that.
> > >
> > > Andrew
> > > _______________________________________________
> > > SM-Sorcery mailing list
> > > SM-Sorcery AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
> > >
> > _______________________________________________
> > SM-Grimoire mailing list
> > SM-Grimoire AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-grimoire
> _______________________________________________
> SM-Sorcery mailing list
> SM-Sorcery AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
>
> _______________________________________________
> SM-Sorcery mailing list
> SM-Sorcery AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
--


Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1

Attachment: signature.asc
Description: This is a digitally signed message part




Archive powered by MHonArc 2.6.24.

Top of Page