SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

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.