[SM-Grimoire-Bugs] [Bug 8646] sorcery 1.11.4: this patch correct INSTALL_ROOT features

bugzilla-daemon at bugs.sourcemage.org bugzilla-daemon at bugs.sourcemage.org
Tue Apr 26 01:54:29 EDT 2005


http://bugs.sourcemage.org/show_bug.cgi?id=8646





------- Additional Comments From sergey at sourcemage.org  2005-04-25 22:54 -------
OK, let me continue on the devil's advocate path a bit longer. I am trying to
think of ways to break the design, so don't take it personally.

(In reply to comment #18)
> default track_root is /, as is install_root. this is to make it so you can
> compile spells for use in an alternate environment seperately from your own, 

Can you describe such environment?

> the other main use is to install stuff 'off to the side', but still use it in your
> main system (not chrooted, or whatever), this is where track_root becomes
> meaningful.

Most spells that need to be installed to the side know about this and don't
care. Those spells that expect to be together with the rest of stuff break with
high probability. Has it occured to you that we've used INSTALL_ROOT in 2000
spells but never made sure it works? Why do you think having TRACK_ROOT and
INSTALL_ROOT is going to? Did you test it?

> 
> The behavior so far has NOT been such that files expect things to be in /, they
> expect them to be in install_root (according to the initial report, which no
> ones actually verified to my knowledge).
> 
> Its unfortunate that install_root was seemingly hastily added with a poorly
> thought out definition and the initial misconceptions and obscurities have
> carried through with it such that virtually every spell assumes one behavior or
> another. The assumption is disambiguated (so far as we know) by the existence of

Could you please explain what do you mean? I have education, so it's not the
word "disambiguated" that I'm asking to clarify. This begs the question that I
asked already, what was done to make sure this new and shiny feature works?

> track_root, again unfortunatly no spell has *ever* made use of it. Believe me,
> im frustrated that years after INSTALL_ROOT was concieved of we're still dealing
> with the consequences of multiple interpritations and attempts at carrying that
> implementation through without considering the others or disambiguating the
> problem first.

So let's not make the same mistake twice.

> 
> As for your depends problem, I cannot answer given the information provided, my

Than please use your imagination and try to think of a spell that doesn't make a
distinction between what we call TRACK and INSTALL locations. It's not uncommon,
especially for non-autoconf/make spells.

> guess is that if its a library it needs to link against, or headers it must
> include, use $INSTALL_ROOT (compile time), the dynamic linker solves the
> location issues at runtime. If its some other program it wants to execute or
> file to find at runtime, then $TRACK_ROOT.

If I'm a perl-based spell and I have perl's path embedded inside; I can also
link against specific perl vm inside per's distribution. The first thing
requires that my DEPENDS uses INSTALL_ROOT, the second -- TRACK_ROOT, if I
understand their meanings correctly.

> 
> As for converting all 3000 spells, this is really only needed for the base
> spells used by the iso and when its convenient. At least thats been my stance
> from the begining. Hence my suggestion to adjust those first.
> 
> Also, for the majority of spells it probably isnt going to mean anything more
> than it does already. Most people dont use either install or track root, so they
> fall through to empty values, it just (slightly) changes the behavior when
> someone is cross compiling or install_rooting to something a bit more realistic
> with what it *should* be.

Right, so why again do we have to commit a 2000+ lines code change again? And
that's just for the grimoire.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



More information about the SM-Grimoire-Bugs mailing list