Re: nosh version 1.37

[Guillermo <gdiazhartusch@gmail.com>]

2018-02-18 20:05 GMT-03:00 Jonathan de Boyne Pollard:
>
> Guillermo:
>
>> This is going to happen for every [GNU/]Linux distribution that is not
>> Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/
>>
>
> That is a reflection of reality.  It isn't very portable.  But you are
> misidentifying what it is.
> [...]
> Guillermo:
>
>> Additionally, the convert/per-user/*.do scripts' 'read_os' function calls
>> 'exec' via absolute path /bin/exec instead of relative path ../../exec,
>> which is not going to work if nosh isn't already installed (chicken and
>> egg).
>>
>
> There's no chicken and egg problem.  The external formats configuration
> import requires (amongst others) the nosh-exec package.
> [...]
> Moreover that is not the relative path from your
> $HOME/.config/service-bundles/convert/ directory to /bin.  Not that there
> of course *is* a stable single relative path for such a thing, given that
> home directories can be anywhere from /export/home/guillermo to
> /var/lib/mysql .  Nor that, as mentioned, such a relative path is needed,
> given that one installs the toolset before running the external
> configuration import.

But wait. You are talking here about run-time requirements / behaviour
of the configuration import subsystem and the service bundles provided
by nosh, after one installs (some equivalent of) the nosh-bundles or
nosh-run-via-systemd packages for the target operating system. I
accept that OS-specific patches might be required here and there to
make them work for the reasons you mentioned.

But the 7 .do scripts I talked about are executed (indirectly) by the
package/compile script from the source package, and they just create
symbolic links. To be precise, they are executed by the source/all.do
script, because they are named in 'echo' commands that feed their
output to the 'xargs -r redo-ifchange' invocation. As it is, on any
[GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL,
downloading the source package and building it slashpackage-style by
executing package/compile will simply fail.

There are warnings in the jdebp.eu webpage about package/stage, but my
expectation was that package/compile would just work (even without a
previous nosh installation), as it has for older versions, provided
the required dependencies are installed (meaning redo, xmlto, ncurses,
pax, etc.). I can work around this by just patching source/all.do so
that it does not execute those .do scripts, or look at what they
should do for Gentoo and patch them, or whatever, but I am sure quite
a few people besides me are going to be surprised by package/compile
failing for them.

(You are right about relative path ../../exec being wrong, it should
be relative to redo's working directory, i.e. ./exec)

G.