README-PACKAGING 4.6 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  1. -*-text-*-
  2. Guile Packaging Guide
  3. Copyright (C) 2002,2004 Free Software Foundation, Inc.
  4. Permission is granted to anyone to make or distribute verbatim copies
  5. of this document as received, in any medium, provided that the
  6. copyright notice and permission notice are preserved,
  7. and that the distributor grants the recipient permission
  8. for further redistribution as permitted by this notice.
  9. Permission is granted to distribute modified versions
  10. of this document, or of portions of it,
  11. under the above conditions, provided also that they
  12. carry prominent notices stating who last changed them,
  13. and that any new or changed statements about the activities
  14. of the Free Software Foundation are approved by the Foundation.
  15. This guide will eventually include comprehensive recommendations for
  16. packaging Guile. Since the guide is still being developed, if you're
  17. planning to package guile for a distribution, say via .debs, .rpms,
  18. etc., please ask questions on the Guile development list at
  19. guile-devel@gnu.org. Packaging Guile in a way that makes future
  20. system upgrades go smoothly and allows multiple major versions of
  21. Guile to coexist peacefully can be tricky. Some initial care in this
  22. regard can save a lot of work later on.
  23. Below is an initial set of issues that are important to consider, and
  24. again, you're always welcome to consult guile-devel. We should be
  25. able to help with any issues that haven't made it here yet.
  26. Libraries:
  27. ----------
  28. Under most packaging systems, it can be very important to package
  29. each shared library in a separate package. However, Guile follows
  30. some conventions that make it's requirements somewhat different. In
  31. order to explain the situaion, we'll first give a brief explanation
  32. of the general issue, followed by a description of how Guile
  33. differs.
  34. For most projects providing shared libraries, it can be important to
  35. place each library in a separate package and to put the the
  36. library's major version number in the name of the package. For
  37. example, rather than libguile.deb or libguile.rpm, you might have
  38. libguile9.deb or libguile9.rpm. This makes it possible for you or
  39. someone else to provide a libguile10 package later that can
  40. peacefully coexist with libguile9. This means that applications
  41. that were compiled against libguile9 can continue to function even
  42. when some new version of Guile providing libguile10 is installed.
  43. If you put more than one library in a package, say libfoo.so.10 and
  44. libbar.so.10, and then in the next release, the upstream developers
  45. increment libfoo to libfoo.so.11, but leave libbar alone, then you
  46. have a problem. Your next library package will conflict with the
  47. previous one because both will contain libbar.so.10 (presuming that
  48. your packaging system considers duplicate files an error). This
  49. means that the old and new library packages cannot be installed
  50. simultaneously, and of course, if the new library package is
  51. installed, and the old one is removed, any software that was linked
  52. against libbar.so.10 will now be broken until it is recompiled. On
  53. the other hand, if libfoo and libbar had been in separate packages,
  54. there would have been no problem.
  55. However, Guile is somewhat unusual because it promises to increment
  56. all of the major versions of all of its shared libraries with the
  57. start of every new stable series (i.e. at release 1.6.0, 1.8.0,
  58. etc.) and Guile also promises that there will be no backward
  59. incompatibilities for libraries released during a stable series
  60. (i.e. when going from 1.6.X to 1.6.Y). This means that unlike many
  61. other projects, it is actually safe to place all of Guile's shared
  62. libraries in one package. For example, Debian places all of the
  63. shared libraries in a guile-1.6-libs package.
  64. Executables:
  65. ------------
  66. It is suggested that the executables be versioned somehow so that
  67. more than one version of guile can be installed at the same time.
  68. This is something that we may eventually address more fully
  69. upstream, but for now, you may want to name the executables
  70. according to the version and then provide some way for symlinks to
  71. be installed from /usr/bin/guile, etc. that point to the actual
  72. executables. i.e.:
  73. /usr/bin/guile -> /usr/bin/guile-1.6
  74. etc.
  75. Debian, for example would handle these symlinks via the
  76. update-alternatives mechanism so that the local admin would be able
  77. to control which version of Guile was the default.
  78. Of course for this to be a really solid approach, we should be
  79. naming things this way upstream and should either use the versioned
  80. names in scripts, i.e. #!/usr/bin/guile-1.6, or have some other way
  81. to make sure the script gets the version of guile it needs.