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: "Reapl Paratorn" <reapl AT reapl.net>
  • 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]
  • Date: Tue, 22 Oct 2002 10:35:19 +1000

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.

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.

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.

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.

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.

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





Archive powered by MHonArc 2.6.24.

Top of Page