Re: execline-1.05 non-root installation problem

Laurent Bercot <[email protected]> wrote:
>  I think I could add support for SP_ROOT in package/compile ; but I'm
> quite reluctant to do it.

So am I. :)  I only support $SP_ROOT in sp-install (and some other
sptools/spf scripts), not in each package's package/* scripts; it
isn't needed there

>  Supporting non-root installations would mean heavy changes in some
> packages like conn-tools, where /package/... paths are hardcoded. The
> whole point in slashpackage is to have reliable paths which _can_ safely
> be hardcoded. I understand this is inconvenient for non-root users, but
> I'm not willing to drop the main slashpackage advantage (for developers
> and admins) because of that.

Here's how I do it.  mkmed depends on prjlibs.  So mkmed has a
conf-compile/depend_prjlibs file, where the user can configure the
path to prjlibs at build time.  Then the build procedure creates a
symlink conf/prjlibs pointing to the configured path, and the full
path to the conf/prjlibs symlink is compiled into the programs.  The
symlink can be changed later, but beyond that, there is no run-time
configurability.  This ought to be good enough for most situations.

Now, if mkmed is installed by sp-install, and $SP_ROOT is set, then
sp-install notices conf-compile/depend_* and edits those files
appropriately before running package/compile.  The package itself does
not (and probably should not) know anything about $SP_ROOT.  All the
needed information is communicated through the conf-compile/* files.
$SP_ROOT is just a way for the user to tell sp-install how to do what
the user would have done by hand if they were not using sp-install.

>  And if you install execline under a different path, #!/command/execlineb
> scripts won't work without patching, which somehow defeats the purpose.

True, but it may still be more useful than no execline at all.

>  On the other hand, if slashpackage users can agree on a "standard" way
> of specifying the /package root, while bearing in mind that only /package
> is fully supported and anything else is the admin's problem, then I'm
> willing to adapt.

I think it's best to make each dependency path, and the package's own
path, configurable as described above, and let higher-level tools like
sp-install handle the more heavy-handed things like $SP_ROOT.  Too
much magic in package/compile scripts will make sp-install a harder
problem.

> For instance, we could define a conf-compile/sp_root file,
> containing /package by default

Nit: $SP_ROOT also applies to /command, etc., so it defaults to the
empty string.  /package and other "absolute" paths are then taken as
relative to $SP_ROOT.


paul