Guten Tag Kristis Makris, am Donnerstag, 20. Dezember 2007 um 15:33 schrieben Sie:
> Perhaps separating > filesystem structure from disk usage, like UNIX systems do, would be the > "correct" solution to this problem. The correct solution is to let the user/administrator decide where to install software cause he, and only he, knows the proper way of doing that. That's the Windows-way, that's because %ProgramFiles% exists and is C:\Programme, F:\Programn Files , F:\Program Files\Mountpoints\D\Program Files(x86) or \\192.168.100.2\Datenserver\SCMBug\somthing very strange. > I use a hardcoded path. I hope this doesn't come as a surprise: a lot of > software on Linux do that! Linux does it that way, and I know a lot of people doing it the "Windows"-way with Linux, but how about Solaris, FreeBSD and all the other stuff out there? SCMBug needs Perl, it shouldn't need the Linux directory structure with every os, in my oppinion. Of course, in my oppinion doing it the Linux-way is simply crap. And of course this is some different discussion. ;-) One example: I have the whole SCMBug-installation versioned in a Subversion-Repository, I just checkout trunk on my server into one directory and everything works. Updates are prepared in an branch and merged to to trunk, afterwards update one directory to get it all running. This won't be that easy if libs, configs and all that stuff is cluttered all over the filesystem. This is one reason I don't use the glue installer provided, too. I don't want any libs, binary data or stuff like that in my repositories directories. The hook-directory is created repository specific under Windows by default by Subversion, there's no need to copy scmbug_activity.pl for example in each of those directories. > They hardcode the path to their configuration file or > some libraries. Their configure script dynamically produces header files > containing absolute paths to the installation directory. Apache, MySQL, PostgreSQL and so on is completely situated under /usr/local/ at our servers, they don't hardcode anything. Providing the installation directory by --prefix=/different/directory while building is nothing more than to configure the "installer" in a user defined way. That's exactly what is MSI designed for with Windows, just lacking the standard gcc. ;-) > In the case of > shared libraries, they assume libraries are available in /usr/lib, and > the OS has a facility of picking them up always from /usr/lib (or > wherever additionally specified). Ever heared of something called "DLL-Hell" with Windows? :-) That's exactly what storing libs in one directory for the whole system is. That's why you have to provide different filenames for each version, which is incompatible with versin contol systems, by the way. I even have Subversion repositories for all our software in use by our customers, this wouldn't be possible if we depend on xerces dlls somewhere in %PATH%, for example. This "DLL-Hell" with Linux is one reason for the people I know installing their software in one directory. > Note: /usr/lib is guaranteed to always be named /usr/lib. Unlike > "Program Files" which could be called something else on Windows > according to architecture and language. This is the distinction, and in > my opinion a limitation of Windows: a lack of filesystem structure > standards. The Windows standard is to use %ProgramFiles%, this is written all over the MSDN as official guidlines. Like don't saving user specific data in /home/tschoening but %USERPROFILE% or %APPDATA%, for example. > You then need to maintain environment variables. e.g. with 15000 > packages on Debian, how many environment variables would one need ? The package manager on Debian, like MSI on Windows, is nothing more than some kind of abstraction layer not to maintain environment variables for each program because they are build on the target platform with the proper configured and afterwards hardcoded installation directories. > That's why Tsahi claims installing in C:\Scmbug is > *wrong* No, installing in C: is wrong because you don't follow the official guidlines for Windows, which, for example, can lead to the user may have write access to the installed data. > I feel that the arguments against absolute paths are arguments against > the lack of standards in Windows. Please lets understand where this is > coming from. Windows does have standards, they only differ from those for Linux. :-) In my oppinion, it's the better way. But this is really a other discussion. The simple conclusion for now is: NO MSI-package, no code changes. I'm interested to see how installjammer will get rid of the absolute-path thing with a Windows installer. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: [EMAIL PROTECTED] Web: http://www.am-soft.de AM-SoFT Potsdam GmbH, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 12480, Geschäftsführer Andreas Muchow _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
