On Saturday, December 07, 2013 03:15:15 PM Paul Moore wrote: > On 7 December 2013 13:45, Michael Jansen <[email protected]> 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
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
