scsh-hackers
[Top] [All Lists]

Re: [Scsh-hackers] Library to ease package installation

To: Anthony Carrico <acarrico@memebeam.org>
Subject: Re: [Scsh-hackers] Library to ease package installation
From: Michel Schinz <Michel.Schinz@epfl.ch>
Date: Mon Nov 17 13:57:29 2003
Cc: scsh hackers <scsh-hackers@lists.sourceforge.net>
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
Le 17 nov. 03, à 07:07, Anthony Carrico a écrit :

On Sun, Nov 16, 2003 at 05:17:00PM +0100, Michel Schinz wrote:

[...]

In my opinion saying that scsh packages are installed with a different
command than "make install" is not such a big deal. What's important is
that this installation procedure is consistent (i.e. all scsh packages
can be installed using the very same command)...

Wait a minute; that doesn't provide any consistency for the user (or
operating system level packager). In theory, they have no idea that
the application/library that they are installing has anything to do
with scsh. Maybe they had never heard of scsh before configure told
them it was required for the application/library at hand.

Well, then I guess we have different views concerning what scsh packages contain. For me, in the current incarnation of the proposal at least, they contain only libraries, not complete applications. Therefore, for me it doesn't really make sense to say that the user who is installing a packages knows nothing about scsh, or that scsh is not installed on the target system.

My impression is that the problem of installing applications on Unix is solved. You know you have to put executables in $prefix/bin, manual pages in $prefix/share/man, and so on. There is no need for us to work on that. And applications written with scsh should follow these conventions just like applications written in other languages.

The problem that I see as unsolved is how to distribute libraries to be used by scsh developers. There is no standard saying where things have to be installed, how files should be called, and so on. That's what the proposal is trying to address.

I think that it could make sense one day to extend the proposal to handle complete applications as well, but for now that's definitely beyond what I had in mind.

"Shall we try an iteration of the current packaging proposal for the
major scsh libraries?"

I vote yes.

"Shall we design our own user interface for installation and
uninstallation, or shall we follow the gnu coding standards
(configure, make install, and make uninstall)"

Considering the current scope I'm considering for this proposal, namely the installation, use and uninstallation of libraries, I vote for our own interface. I could reconsider this if we decided to widen the scope to include full applications.

Michel.



<Prev in Thread] Current Thread [Next in Thread>