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

[Michael Jansen]

On Saturday, December 07, 2013 03:15:15 PM Paul Moore wrote:
> On 7 December 2013 13:45, Michael Jansen <info at michael-jansen.biz> wrote:

> 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.

And thats where i disagree. I have some experience in open source contributions (KDE, cobbler 
and my own).

1. Usable code always wins. Always. Ideas and Agreements solve nothing.

2. This is a already solved problem. Both autotools and even more so cmake make it possible to 
develop cross platform. Why python should be differently is something i won't understand.

If you want to wait for a compromise and an agreement nothing will ever be implemented.

> 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...

A windows developer should not care about the difference. Both end up in the same directory. A 
unix developer will either not care too (and be reminded by the distro) or has read

http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

So the not caring unix/windows developer will one day get a bug report/patch from a unix user or 
distro packager if some script belongs to sbin.

> 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.

Thats why i prefer to improve step by step. The sbin/bin distinction can be solved in a platform 
neutral way so why not do it.

> 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 :-)

It most likely will never run on windows but i have seen weirder things (productive clearcase 
running on windows xp *shudder*). But there is nothing that prevents it from ever running on 
windows. So if i solved the multi distro support there is nothing that prevents someone to make it 
running under windows. Why shouldn't you boot and provision your unix virtual machines with a 
server running on windows? But i guess its unlikely.

And its not my project. I only contribute since about three weeks. My homepage says something 
about "drive-by coding" and thats what i do. I like the project and noticed it currently only runs on 
redhat and installed into /usr. There are people using it on sles (its a rather enterprisey thing) 
which use patches.

So i solved all obstacles to get it running out of the box (with correct paths) on opensuse already 
and thought i could do another attempt to get those improvements that make sense into 
setuptools. But i think that won't happen.

And it was not you. I like to discuss and i always applaud people that help other brainstorm.

Anyway. I will solve my problems on top of setuptools for cobblerd only for now. Then i will think 
about what to do with the results.

I need and partially have solution for:

  - configure some files (patch @@var@@) (implemented)
    - eg. patch VIRTUALENV into a apache config file for wsgi virtualenv support
    - patch some distro / platform specific paths in config files.
  - install scripts in locations != bin (sbin and some wsgi) (implemented)
  - support for share/<package>  (not yet)
  - support for /etc (different for prefix=/usr|/usr/local) (not yet)
  - support for /var (not yet)
  - support for /srv/www (sometimes its /var/www (done)

Currently all those pathes are just done with data_files which makes multi distro support quite 
complicated there.

Yes this is mostly linux distro stuff but some of it could be useful for windows too.

Mike

-- 
Michael Jansen
http://michael-jansen.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131207/27093082/attachment-0001.html>