Re: "tla build-config" question and suggestion

Ludovic Courtès wrote:
> Beside Tom's authority, I believe the rationale is that paths in configs
> should be relative to the tree root and should only designate locations
> _within_ that tree root.  Hence, it is a good thing for a path starting
> with `..' to be rejected.  Same for an absolute path.
>
>   
Right.   It's been sufficiently long that I don't recall whether or not
I properly made the code robust against symlink trickiness -- that
might be worth double-checking.

> Now, it seems that `is_non_upwards_relative_path ()' would also reject
> paths like `chbouib/../foo' which theoretically it should accept.  But
> well, arguably, that shouldn't be too much of a problem.  ;-)
>   
The simpler rule is easy to explain and handling that generality properly
would be pretty tricky.   As it stands, given a list of config file 
destination
directories, you can compute a construction order for the tree just by 
sorting
the names primarily from shallowest to deepest.   How would you handle
`a/../b'?   If you don't canonicalize it at all, you don't get a proper 
construction
order.   If you canonicalize it symbolically (e.g., always to `b') then 
you're
using a non-standard canonicalization function.   If you canonicalize it
using `namei', then you can no longer compute a construction order from
just the directory names: you would have to figure out an order by either
examining the contents of revisions or by building them and looking at the
result.

Of those other possibilities, canonicalizing such names using `namei' is 
the only
one that's semantically sane.   It wouldn't be (let's say) any harder to 
code than
the algorithm that's there -- only different.   But then, supposing 
that's how it
worked, given just a config file:  draw a picture of the skeleton of the 
resulting
tree, labeling nodes with the arch name of the thing to be put there.   You
can't do it.   So while semantically clean, the `namei' method would 
lose some
interesting functionality.

Which leaves ... just exactly what's there.   Semantically clean.   
Sufficiently
powerful.  Ensures that config files tell you something interesting about
the structure of the resulting tree.  (Except, as I say, the code *should*
be sure that no element of the relative paths is a symbolic link and I 
really
don't recall if it actually does.)

-t