mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-12 23:00:22 +02:00
*** empty log message ***
This commit is contained in:
parent
9d3fa3f3cc
commit
8e35ae8326
2 changed files with 84 additions and 0 deletions
5
INSTALL
5
INSTALL
|
@ -15,6 +15,11 @@ Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
|
||||||
of the Free Software Foundation are approved by the Foundation.
|
of the Free Software Foundation are approved by the Foundation.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Note to Guile Packagers (Distributors) ====================================
|
||||||
|
|
||||||
|
Please see ./README-PACKAGING.
|
||||||
|
|
||||||
Brief Installation Instructions ===========================================
|
Brief Installation Instructions ===========================================
|
||||||
|
|
||||||
To build Guile on unix, there are two basic steps:
|
To build Guile on unix, there are two basic steps:
|
||||||
|
|
79
README-PACKAGING
Normal file
79
README-PACKAGING
Normal file
|
@ -0,0 +1,79 @@
|
||||||
|
-*-text-*-
|
||||||
|
Guile Packaging Guide
|
||||||
|
Copyright (C) 2002 Free Software Foundation, Inc.
|
||||||
|
|
||||||
|
Permission is granted to anyone to make or distribute verbatim copies
|
||||||
|
of this document as received, in any medium, provided that the
|
||||||
|
copyright notice and permission notice are preserved,
|
||||||
|
and that the distributor grants the recipient permission
|
||||||
|
for further redistribution as permitted by this notice.
|
||||||
|
|
||||||
|
Permission is granted to distribute modified versions
|
||||||
|
of this document, or of portions of it,
|
||||||
|
under the above conditions, provided also that they
|
||||||
|
carry prominent notices stating who last changed them,
|
||||||
|
and that any new or changed statements about the activities
|
||||||
|
of the Free Software Foundation are approved by the Foundation.
|
||||||
|
|
||||||
|
|
||||||
|
This guide will eventually include comprehensive recommendations for
|
||||||
|
packaging Guile. Since the guide is still being developed, if you're
|
||||||
|
planning to package guile for a distribution, say via .debs, .rpms,
|
||||||
|
etc., please ask questions on the Guile development list at
|
||||||
|
guile-devel@gnu.org. Packaging Guile in a way that makes future
|
||||||
|
system upgrades go smoothly and allows multiple major versions of
|
||||||
|
Guile to coexist peacefully can be tricky. Some initial care in this
|
||||||
|
regard can save a lot of work later on.
|
||||||
|
|
||||||
|
Below is an initial set of issues that are important to consider, and
|
||||||
|
keep in mind that you're always welcome to consult guile-devel. There
|
||||||
|
we should be able to help with any issues that haven't made it here
|
||||||
|
yet.
|
||||||
|
|
||||||
|
Libraries:
|
||||||
|
----------
|
||||||
|
|
||||||
|
Under most packaging systems, it is very important to package each
|
||||||
|
shared library in a separate package and you should generally
|
||||||
|
include the library's major version number in the name of the
|
||||||
|
package. For example, rather than libguile.deb or libguile.rpm, you
|
||||||
|
might have libguile9.deb or libguile9.rpm. This makes it possible
|
||||||
|
for you or someone else to provide a libguile10 package later that
|
||||||
|
can peacefully coexist with libguile9. This means that applications
|
||||||
|
that were compiled against libguile9 can continue to function even
|
||||||
|
when some new version of Guile providing libguile10 is installed.
|
||||||
|
|
||||||
|
One question might be "Why separate library packages? Why not just
|
||||||
|
have a giant guile-A package and later a giant guile-B package, each
|
||||||
|
of which contains all of the needed libraries and other files?" One
|
||||||
|
problem with this approach is that it prevents a new version of
|
||||||
|
Guile from including some libraries whose major numbers have changed
|
||||||
|
and some whose major numbers haven't. The older and newer Guile
|
||||||
|
packages would have overlapping files, but the newer package
|
||||||
|
wouldn't be a complete and transparent replacement for the older
|
||||||
|
one.
|
||||||
|
|
||||||
|
Executables:
|
||||||
|
------------
|
||||||
|
|
||||||
|
It is suggested that the executables be versioned somehow so that
|
||||||
|
more than one version of guile can be installed at the same time.
|
||||||
|
This is something that we may eventually address more fully
|
||||||
|
upstream, but for now, you may want to name the executables
|
||||||
|
according to the version and then provide some way for symlinks to
|
||||||
|
be installed from /usr/bin/guile, etc. that point to the actual
|
||||||
|
executables. i.e.:
|
||||||
|
|
||||||
|
/usr/bin/guile -> /usr/bin/guile-1.6
|
||||||
|
etc.
|
||||||
|
|
||||||
|
Debian, for example would handle these symlinks via the
|
||||||
|
update-alternatives mechanism so that the local admin would have
|
||||||
|
control over which version of Guile was the default, if they didn't
|
||||||
|
want the one specified by the packages.
|
||||||
|
|
||||||
|
Of course for this to be a really solid approach, we should be
|
||||||
|
naming things this way upstream and should either use the versioned
|
||||||
|
names in scripts, i.e. #!/usr/bin/guile-1.6, or haves some other way
|
||||||
|
to make sure the script gets the version of guile it needs.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue