SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

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





------- Additional Comments From acedit AT armory.com  2005-04-25 23:47 -------
(In reply to comment #22)
> 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.

Dont worry im not, but just so long is its as much fun for you as it is for 
me.
I love defending a problem thats been solved for almost a year now and a few
people are just now becoming aware of it. So just remember, most of this
discussion is a rehash of issues already discussed, sorry you missed the boat.
This wouldve been a good discussion when the ideas were first put forth. 
Also, I
really want to stress that most of the debate below has little to do with what
this bug is actually about.

> 
> (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?
cross compiling, the spells are build with the expectation they will be run 
from
inside $TRACK_ROOT but installed to $INSTALL_ROOT.

> 
> > 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.
And this change shouldnt effect any of them in a positive or negative way 
except
for the 42 described by seth's previous post

> Those spells that expect to be together with the rest of stuff break with
> high probability.
As is the case in a cross compile environment, which is further disambiguated 
by
checking the cross compile flag.

>  Has it occured to you that we've used INSTALL_ROOT in 2000
> spells but never made sure it works? 
Yes, and i personally dont care since as ive said the head-first approach to
install_root was completely wrong and this only matters for spells which we 
need
it to matter. Which, in case we forgot, are those needed for the iso.

> Why do you think having TRACK_ROOT and
> INSTALL_ROOT is going to? Did you test it?
What do I think it will do? It will do what the functionality was *meant* to 
do
and was discussed almost a year ago, and ive laid out repeatedly, im getting
tired of repeating myself, read the wiki. Again if spells not using the 
defaults
do the wrong thing thats *not* my problem. Im concerned with spells that use 
the
default functions, and we only have 42 spells not using autoconf that are 
effected.

Benoit has claimed to test it, at least against autoconfed spells, which is 
all
the default functions have refer to.

> > 
> > 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?

For one, this isnt a shiny new feature, sorcery has done this for almost a 
year.
 Track_root seperates two conflicting ideas on what install_root means. Some
people say install_root means "install files to $INSTALL_ROOT and expect
everything else to be there" others say it means "install files to 
$INSTALL_ROOT
and thats *it*, just a literal transplant of what would've gone to /, but
instead in $INSTALL_ROOT". TRACK_ROOT differentiates between the two, if
$TRACK_ROOT is / then its the first case, if $TRACK_ROOT is $INSTALL_ROOT then
its the second. In other words, no more debate. And of course, you're not
limited to those two combinations.

> > 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.

Agreed. This is why there was a meeting a year ago to figure it out and why i
vehemently refused to work on the feature or support it in any way before that
occured. However, if spells dont observe it, its not my problem. Its also not 
my
problem that the mis-informed went headlong into using the ambiguous
$INSTALL_ROOT value and coded their stuff one way while others coded theirs a
different way, so, no one wins. We've known that for a while, lets move on
already. And once again, this adjustment to the *default* functions shouldnt
mean a whole lot to most spells except for a mere 42 according to seth.

> 
> > 
> > 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.

Then that spell is not fully convertable, or you didnt try hard enough
converting it. I only care about autoconf spells using this functionality and
about the defacto case where the values fall through, so it doesnt matter.

> 
> > 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.

Perl is broken then, or you're not trying hard enough, again not my problem 
and
out of the scope of this bug considering the variables were defined a long 
time
ago and if external software wants to ignore reality theres nothing *sorcery*
can do about it. If you close your eyes the laws of physics dont just go away,
so its, again, not my fault for simply providing a configurable interface to 
it.
What other software chooses to do with it is of no concern to me.

> 
> > 
> > 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.

I didnt say that. Also, the grimoire is the only thing that needs changing (if
we continue along this false assumption that all spells need updating, which i
have not been saying is the case), this concept has been in sorcery for 
nearly a
year and is working just fine, so the only changes needed are to the
default_build and install functions which are only a convenience for spells. 
If
we had a perfectly disjoint build engine and spells then this wouldnt have
anything to do with sorcery at all since all sorcery would provide are the
variables INSTALL_ROOT and TRACK_ROOT along with their defined meanings.

If you want to ignore the meanings of these variables or assume one meaning or
another (which is what has already been the case for either interpritation, so
its really no change) then thats fine by me, cause I really dont care! My only
investments in this conversation are:

1) preserving the existence of concepts (which I believe are part of the
'physics' of build systems) despite opposition which I know will result in
regressing back to pointless debate on ambiguous concepts (which are
disambiguated by seperating the concepts)

2) getting the next 1.13 sorcery release out

3) facilitating the ease of iso generation via sorcery without the use of
unsupported patches no one has discussed

4) just being nice and not wanting to unnecessarily break spells if I can 
avoid it

Notice the list above does not contain any points about me (where me == 
sorcery,
or the sorcery team) caring what people do with the variables. If you're 
looking
at a physics problem and ignore something, the underlying rules dont change,
just means something doesnt work right. I am sympathetic to the lack of full
integration with the variables, but some spells were broken before track_root
was concieved so its no surprise nothing has changed. So, like ive been 
saying,
most spells dont even know since the variables have no value for regular use,
and when they do have a meaning its up to the user (iso team) to update them 
to
work. The issue here is getting the default actions correct.

Besides, most of the discussion aboive has absolutly nothing to do with this 
bug
to begin with, this conversation would have problem been a lot more useful a
year ago when these ideas were first put on the table.

Also, I dont know where you're getting the idea that this requires changes to
all spells, or how this is significantly different than whats already the 
case,
the true meanings of the variables havent changed it all. This really doesnt
change the meaning of install_root in any way, track_root simply fills in the
'where does this run from' shaped hole. Again lots of spells ignore this, so 
its
no change.

-- 
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.