From: Austin Ziegler <austin@...>
Date: 2002-11-09T10:48:00+09:00
Subject: Re: CPAN Style installer

On Sat, 9 Nov 2002 08:58:08 +0900, Yohanes Santoso wrote:
> Austin Ziegler <austin@halostatue.ca> writes:
>> ALL packagers should know what was installed and where; if they
>> don't, then there's a problem (even RPM knows this stuff). 
Windows'
> I agree that all package manager should know what and where they
> install! But, like I said in the example with Debian's package
> manager, for the package manager to know all installed files, it
> requires some additional work from the package builder.

This is a problem of the package manager, frankly. The only time
that this is something that could require work on the matter of the
package maintainer is for files generated during installation --
like Perl when it generates its HTML help files during installation
(at least on Windows using the AS installer).

> If the package consists of exclusively ruby files, then the
> package builder can just assume that that's all in that package.
> Howeveer, if a package needs to be compiled, and the compilation
> produces a bunch of object files, then the person doing the
> packaging have to add manually/semi-automatically each created
> object files and/or config files into the list of files of that
> package.

This applies only when you're compiling the file(s) from scratch,
which may not always be the case. It is also possible to have the
packaging system parse the makefile(s) used to determine the targets
which need to be included. (Then again, I'm curious how the package
system would know which binary items to install in the first place,
and why telling the package this couldn't also initiate the build
process, if necessary.)

> GNU stow is a solution towards this put-all-in-one-place thinking.
> You may not like it the way it works, but you gotta love the
> simplicity it produces.

Actually, I don't like stow at all, because it depends on symbolic
links, which is not a remotely useful solution except on Unix boxes
-- and I personally wouldn't use stow on my Unix boxes at all.
(Ultimately, stow doesn't solve the *problems* of single
installation places, which are conflicting dynamic library versions,
and instead adds an unnecessary indirection.)

> For example, in Debian, kde3 is still not officially included.
> [...]

Um ... when I tried Debian (for all of two hours when I decided that
the installation process sucked so much that I didn't want to deal
with it), KDE3 was included.

> Finally, installing a package in your own home directory may work
> in some cases. But what if you're working with a group of people.

Most package installers on unix support the specificaion of
alternate prefixes -- allowing installation in $HOME, /usr, or
anything else.

> In this case, the sensible solution is to install the package in a
> centrally accessible place. May be in Windows where only one
> person works on a machine, there is no difference between home
> directory installation vs. central installation.

You're completely wrong here. There is, at least with all NT-based
versions, and to some degree with 9x versions, limited ways of
supporting "local" installations. (NT-based versions have
significantly more flexibility here.) There is actually a difference
in installation.

> My point is, DOS had it right by putting each application in its 
own
> directory. Windows had it wrong. Unix, CPAN, etc. also had it
> wrong. There's no sense in continuing an otherwise bad practice.

Stow, however, doesn't fix the actual problem with this allegedly
bad practice. The *problem* here isn't /usr/lib or
\windows\system32, but with conflicting library versions and no
clean way of managing it. Stow doesn't fix this. Neither does going
back to statically compiled binaries or replicating libraries in the
directories of all binaries.

> libcygwin, for all its faults, have managed to implement link in
> Windows filesystem.

No, it hasn't. It simulates it by creating files that point to the
actual file. It's not a filesystem solution. It only works on
programs which use the filesystem functions *in* libcygwin itself --
which is a tiny percentage of the programs which would be used in
any given Windows installation.

> Even if libcygwin has more faults than goodness, there are many
> other UNIX emulations layer that implements file link in Windows.
> Furthermore, it should be noted that it is possible to pick just
> what you want from a library, especially one whose source code is
> open.

Sorry, but it isn't possible -- because the OS filesystem itself is
closed.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.11.08 at 19.19.56