I hope we don't get into another long discussion section. I could almost swear I could have written an installer by now :)
On Thu, 2007-12-20 at 13:43 +0100, Thorsten Schöning wrote:
> Guten Tag Kristis Makris,
> am Donnerstag, 20. Dezember 2007 um 13:16 schrieben Sie:
> > I'm not sure what or why we are arguing anymore. You WILL need to write
> > code such as:
>
> > if ( $PRODUCT_ON_WINDOWS) {
> > # Read the %Program Files% environment variable and use it
> > # Or read the %SCMBUG_HOME% environment variable and use it.
> > }
>
> How do you handle the code with a hardcoded, absolute Windows path on
> Linux? Two possibilities: Either you use a hardcoded path on Linux,
> too, which is not the way to go in my oppinion, or there's no code
Why is this not the way to go ? What would the problems be ? Wanting to
move the software ? Why ? Is the disk full ? Perhaps separating
filesystem structure from disk usage, like UNIX systems do, would be the
"correct" solution to this problem. But it's still a problem in Windows,
and we'll try to deal with it.
I use a hardcoded path. I hope this doesn't come as a surprise: a lot of
software on Linux do that! e.g. PostgreSQL/MySQL, gcc/icc compilers,
samba, apache. 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. 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).
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.
> where you would need a absolute path on Linux, I don't believe that.
> If you somewhere need a path, just don't use a hardcoded one on any
> platform, but ALWAYS use some kind of configuration, like an
> environment variable, and you DON'T have to write platform specific
> code.
You then need to maintain environment variables. e.g. with 15000
packages on Debian, how many environment variables would one need ? Can
the environment hold that many variables ? Should the user manually
create those for each software that lacks a proper installer ? This
approach does not scale.
The problem of "wanting to install the software in a different
directory" is solved by recompiling the software with
--prefix=/different/directory. In most cases, because of standards, you
don't need to install in exotic places. rpms/debs etc install
in /usr/lib, or /usr/local, or /usr/opt. Not
in /scmbug_foundation/testing, /custom/dir, etc. The "standard" is
that /usr, /usr/local exist (not sure about /opt). And because of
standards sysadmins allocate enough space to /usr and /usr/local.
The *problem* with Windows is drive letters. Why have drive letters ?
It's better to have a filesystem whose structure can be mounted on
different drives. An undetermined number of drives makes the structure
unpredictable. That's why Tsahi claims installing in C:\Scmbug is
*wrong*, while at the same time installing in /usr/share/lib/scmbug
isn't. Both are absolute paths, but the underlying disk storage is
configurable in Unix but not Windows.
This is a separate discussion, but I disagree that changing drive
letters in Windows will break 90% of applications. It's possible to
write a backwards-compatible filesystem that will interpret all
references to drive letters and point them e.g. to /mnt/c, /mnt/d, etc
and break precisely 0% of the applications. The point is the problem can
be fixed in Windows, and it hasn't. And the end-result is still a lack
of standards. If they were to fix it, they'd probably arrive to the
conclusion that they need to have a filesystem structure standard.
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.
In any case, we'll deal with the problem.
> > Thus you WILL need to do something
> > dynamically during installation time. Thus you WILL need an installer
> > that does it for you.
>
> The user wanted an installer, or some other kind aut automatism, which
> will do anything he has to do manually, remember? He wanted that
> something installs the service, the program in any path he wants etc.
> I just showed one way to achieve this without too much work.
I understand this Thorsten and I'm always grateful for the feedback. But
this is a non-automated (and non-scaleable if you look at all
applications going into a system) approach. The current "installer"
provides an automated, scaleable, maintainable method, despite its
flaws. I suppose I'd rather place more ephasis on keeping things
automated and maintainable.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
