[Distutils] Install a script to <prefix>/sbin instead of <prefix>/bin

[Paul Moore]

On 7 December 2013 13:45, Michael Jansen <info at michael-jansen.biz> wrote:
> Anyway. You are at least willing to discuss with me. So thanks.

No problem! I hope I wasn't too discouraging - I get the impression
that I was :-(

My problem is that I don't know the answers on Windows, I only really
know enough to know when something feels wrong. In this area, Unix and
Windows really are very different, and it shows. Very few people are
willing or able to put the effort into developing cross-platform
solutions, and those that do are too busy doing it to worry about
establishing general principles, etc.

> I guess i give up on improving setuptools and instead just implement enough
> to fix cobblerd. After that i guess i will take with me the hope that the
> next time i have contact with python packaging the situation improved but i
> had that hope ten years ago too :( .

I can understand your situation, but please don't give up! The
packaging community definitely needs people willing to help work on
these issues. But it's much less about coding solutions, and more
about negotiating compromises between people with very different
viewpoints.

To go back to your original issue (sbin vs bin) - from my point of
view as a Windows developer, packages just export commands. Why would
I choose to put them in the sbin list rather than the bin list? If
that's not clear, then I'll possibly develop packages that don't work
"right" on Unix. Let's thrash out the answer to that question first,
and *then* worry about implementing it. Is the relevant point that
"bin" is on PATH but sbin (typically) isn't? If both are on PATH, I
don't see why you bother having two directories. So maybe the real
idea here is to split entry points into "commands that should be on
PATH" and "commands that should be provided, but not on PATH by
default". Or is it? My understanding of sbin on Unix is that it's
somehow "system utilities" - but that's just a classification with no
practical impact. (What makes formatting a disk a "system utility"? I
used to do it all the time when floppy disks were common.) Or maybe
sbin is only on PATH when you're root. How does that translate to
typical Windows systems, where there is usually only one user, and he
has access to everything? Maybe in that context, sbin should be for
utilities that require elevation? Lots of questions, but no obvious
answers...

As I said, and I'll say again, you don't *have* to answer these
questions. But not doing so is not "I don't want to think about it,
just solve POSIX". Rather it's "let's not make everything wait for a
perfect solution when POSIX people need something now". But equally,
let's not stop working on the cross-platform solution because the
POSIX people have something and no longer care - that's *why* the
problem never gets solved properly.

One other thing I should say here - you mention your project is
"cobblerd". The "d" on the end makes me thing it's a daemon. That's
inherently POSIX only - on Windows this would be a service (which is a
whole other beast). Actually looking at Cobbler on PyPI it says
"Cobbler is a Linux boot server..." so Windows compatibility really
isn't crucial in this particular instance, I guess :-)

Paul