On Sat, 21 Dec 2019 23:46:34 +0000
"Laurent Bercot" <ska-supervision_at_skarnet.org> wrote:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.
> The current version of execline includes POSIX-compliant cd and wait
> binaries, and the next one will also include a POSIX-compliant umask
> binary. Then we shall see what new excuse they find not to put
> execline binaries in the default PATH.
My finding in the past is that Debian will do harm to any software just
so they can comply with their arcane rules. One such rule caused them
to change the prepend key-sequence in VimOutliner from the incredibly
quick and easy double comma (,,) to the wrist-twisting, error prone,
slow, and keyboard dependent double backslash (\\), even though
VimOutliner's manifesto listed authoring speed as the top priority.
That being said, is having your stuff on the executable path such an
advantage? A lot of times I put all the executables for a system in a
directory off the path, and then create a shellscript like this:
====================================
#!/bin/sh
export PATH=/path/to/s6:$PATH
$_at_
====================================
Or this:
====================================
#!/bin/execlineb -s1
importas OLDPATH PATH
export PATH "/path/to/s6:$OLDPATH"
$1 $_at_
====================================
Symlink the shellscript from a directory on the path, and whatever is
in $_at_ is as good as being on the path. By doing this I avoid any
program name conflicts, I can easily delete my whole program or copy it
to another computer. And of course slashpackage is another way.
I'm not saying this is perfect. I'm just saying it could be as simple
a opening a tarball in an arbitrary directory and typing make; make
install. That's basically how we distributed VimOutliner for a long
time. Earlier in this thread somebody suggested a method of Debian
packaging that was both breathtaking in its convolution and
preventing of other software from being installed at the same time. With
Debian's propensity to break things doing them their way, perhaps it's
time to consider the possibility of doing an end run around the Debian
Developers.
SteveT
Steve Litt
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
Received on Sun Dec 22 2019 - 20:33:27 UTC