Re: resolution of symlinks in asdf

Kevin Layer <[email protected]> writes:

> Christophe Rhodes <[email protected]> wrote:
>
>>> Well, you might need to change my example code, given that you've
>>> provided no details of the filesystem layout.  
>
> Your comments about filesystem layout don't make any sense to me.
> What does that have to do with anything?

You are attempting to customize where asdf puts its binary files
because of a particular use at your site.  Yes or no?  Or are you
trying to customize where asdf puts its binary files at all sites
everywhere?  My understanding was that you have your 17 symlink-farm
directories and you want to place the binaries alongside the symlinks,
and that you have control over this filesystem, and that this is not
the same setup as anywhere else.

The reason this is my understanding is from your initial mail on this
subject, when you said:

| A contractor of Franz recently used asdf on a project.  When I went to
| integrate the project into our sources and build system I found it
| didn't work.  We use (and have for 15+ years) binary symlink
| directories (currently there are 17 of them, each one corresponding to
| one non-windows port of Allegro) to a single source directory.  Each
| binary directory mirrors the structure of the source directory, except
| all source files are symlinks to the ones in the source directory.

Since I presume the contractor of Franz used asdf successfully, it is
not a property of the system that needs to be changed.  (If the
contractor wrote an asdf system and did not ever use asdf successfully
to build the system, you should probably take that up with your
contractor.)

If I've misunderstood your aim, please say so.  If there are other
salient details about your aim that might help in understanding,
please say so.  My current belief is that that if we can get you to
have, at your site, binary files going into the same directory as the
symlink to the system file, that will be useful to you; if that's not
the case, please say so.  (Or if there are other requirements, please
say so.)

> I'm from the school of development that all of software I've
> compiled uses.  I'm talking about software I've downloaded and
> installed myself.  Going back to the early 80's.  You download
> something.  You extract it.  You build it.  The binaries go in the
> relative directory where you extracted.  The installation is the
> only thing which copies/moves things outside this relative
> directory.

Amusingly, this is a very precise description of asdf's current
behaviour, though I think I know what you were trying to say.

>>> A :resolve-symlinks keyword is a non-starter from my point of view,
>>> because though it might be intended for use just at your site, 
>
> I disagree.  It would be used by anyone that wants the behavior I
> describe above.  Why is this so foreign to you?  Every single package
> that you can download from the FSF behaves this way.

Just because something can be used to cause behaviour similar to
something else does not mean that it is a good idea.  That doesn't
necessarily mean that the behaviour itself is a bad idea -- as far as
I'm concerned, your wanted behaviour at your site is fine -- but it
doesn't necessarily bless the mechanism as being the right thing
either.  Yes, other people might want the same kind of behaviour in
the presence of symlinks that you do; that's fine too -- but it
doesn't make it a property of the system.

>>> once it is there, people will use it in a mistaken belief that
>>> their site is the only site in the world that matters; code using
>>> it will get out into the wild, and then _we_ will have a support
>>> burden (consider questions of the form "why doesn't asdf-install
>>> work?").
>
> Your worried about someone that specified :resolve-symlinks t and uses
> asdf-install and complains?  :resolve-symlinks defaults to nil.

I am worried that person A specifies :resolve-symlinks t in some code
that they developed, and person B tries to use it, and discovers that
because person A has some particular filesystem layout preferences
person B's (and person C's, and person D's...) system utilities (such
as asdf-install) fail to work on person A's code.

This might well be the critical point, so say if it isn't clear why
this is important.

>>> Have you considered using hard links instead of symbolic links in your
>>> filesystem?  
>
> The symlinks are cross-machine.  hard links work within a single
> filesystem.

Yes.  (Thanks for providing a tidbit of information.)

>>> Or reworking your patch in the light of suggestions I've
>>> made already?
>
> What suggestions?  The only one I see if using the output-files
> method?  The only way that can work is if there is some hardwired
> directory structure into which the binaries are put.  That is a deal
> breaker.

Really quite a long way upthread now, I said:

| This is kind of workaroundy, and it might well make sense to
| distinguish between the system-pathname and the system-truename in
| the information preserved by the system, so that better output-files
| methods can be written.

and I believe that if it were possible to distinguish between
system-unresolved-pathname and system-resolved-pathname (not
system-pathname and system-truename, of course, because some Lisp
implementations consider symlinks to be truenames) then you could
write an output-files method to run at your site that did not hardwire
anything.

>>> Following symbolic links provides a mechanism for achieving certain
>>> things, yes.  However, it really isn't a property of the system,
>>> because the site administrator, through their control of the
>>> filesystem, has the ability to choose whether this mechanism is
>>> invoked or not.
>
> The only choice I see is whether or not to use symbolic links in the
> first place.   What choice are you talking about?

That looks like a choice to me.  It's not a perfect choice, and it may
not be acceptable to you, and you may need to do some work to add some
extra choice.  (I appreciate that you have already done so, with your
initial patch; I am trying to explain to you why that patch is not
suitable for general distribution, and attempting to explain what
would improve it.)

>>> Forgive me for being blunt: you are not providing enough evidence
>>> in your messages that you are reading mine with enough care to
>>> extract information and ideas from them, and you are not providing
>>> any information in your own for me to respond to.
>
> I'm sorry you feel that way.

But apparently not sorry enough to review this thread for pieces of
information that you might have missed.  Perhaps instead of being
sorry about my feelings you could change your behaviour?  (I am of
course aware that that particular expression of apparent contrition is
usually nothing of the sort, but I'll try not to let that affect my
judgment.)

Cheers,

Christophe