openpkg/lsync.pod

Tue, 06 Jan 2009 23:45:10 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Tue, 06 Jan 2009 23:45:10 +0100
changeset 16
01c515740aeb
child 428
f880f219c566
permissions
-rw-r--r--

Include well tested and long contributed C++ version logic as a patch.

michael@13 1 ##
michael@13 2 ## lsync.pod -- Access Layer Synchronization Tool (Manual Page)
michael@13 3 ## Copyright (c) 2000-2007 OpenPKG Foundation e.V. <http://openpkg.net/>
michael@13 4 ## Copyright (c) 2000-2007 Ralf S. Engelschall <http://engelschall.com/>
michael@13 5 ##
michael@13 6 ## Permission to use, copy, modify, and distribute this software for
michael@13 7 ## any purpose with or without fee is hereby granted, provided that
michael@13 8 ## the above copyright notice and this permission notice appear in all
michael@13 9 ## copies.
michael@13 10 ##
michael@13 11 ## THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
michael@13 12 ## WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
michael@13 13 ## MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
michael@13 14 ## IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
michael@13 15 ## CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
michael@13 16 ## SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
michael@13 17 ## LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
michael@13 18 ## USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
michael@13 19 ## ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
michael@13 20 ## OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
michael@13 21 ## OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
michael@13 22 ## SUCH DAMAGE.
michael@13 23 ##
michael@13 24
michael@13 25 =pod
michael@13 26
michael@13 27 =head1 NAME
michael@13 28
michael@13 29 B<openpkg lsync> - Access Layer Synchronization Tool
michael@13 30
michael@13 31 =head1 SYNOPSIS
michael@13 32
michael@13 33 B<openpkg lsync>
michael@13 34 [B<--version>|B<-v>]
michael@13 35 [B<--help>|B<-h>]
michael@13 36 [B<--init>|B<-i>]
michael@13 37 [B<--nop>|B<-n>]
michael@13 38 [B<--quiet>|B<-q>]
michael@13 39 [B<--trace>|B<-t>]
michael@13 40 [B<--local>|B<-l>]
michael@13 41 [B<--uninstall>|B<-u>]
michael@13 42 [B<--root=>I<root>]
michael@13 43 [B<--pkgdir=>I<pkgdir>]
michael@13 44 [B<--subdirs=>I<subdir>[,I<subdir>,...]]
michael@13 45
michael@13 46 =head1 DESCRIPTION
michael@13 47
michael@13 48 This program activates software packages which were locally
michael@13 49 installed in a sub-directory of a package hierarchy (located under
michael@13 50 I<root>/I<pkgdir>/) by managing symbolic links in an access layer
michael@13 51 (located under I<root>/) corresponding to package installation
michael@13 52 files (found in I<root>/I<pkgdir>/pkgname/subdir/) which need to be
michael@13 53 collected in global directories (located under I<root>/subdir/).
michael@13 54
michael@13 55 The purpose of this is that individual packages can be installed and
michael@13 56 deinstalled seperately without interfering with other packages while
michael@13 57 all packages as a whole still can be treated like a single package
michael@13 58 (installed into the access layer).
michael@13 59
michael@13 60 The
michael@13 61 actual creation of symbolic links is as following ("foo" indicating an
michael@13 62 arbitrary file; "bar" indicating an arbitrary package name):
michael@13 63
michael@13 64 =over 4
michael@13 65
michael@13 66 =item I<root>B</bin/>foo -> B<../>I<pkgdir>B</>barB</bin/>foo
michael@13 67
michael@13 68 This activates the user executeable
michael@13 69 I<root>B</>I<pkgdir>B</>barB</bin>/foo as I<root>B</bin/>foo. It can
michael@13 70 be found by the shell by placing I<root>B</bin> into the environment
michael@13 71 variable C<PATH> (B<PATH="..:>I<root>B</bin:..">).
michael@13 72
michael@13 73 =item I<root>B</sbin/>foo -> B<../>I<pkgdir>B</>barB</sbin/>foo
michael@13 74
michael@13 75 This activates the system executeable
michael@13 76 I<root>B</>I<pkgdir>B</>barB</sbin>/foo as I<root>B</sbin/>foo. It can
michael@13 77 be found by the shell by placing I<root>B</sbin> into the environment
michael@13 78 variable C<PATH> (B<PATH="..:>I<root>B</sbin:..">).
michael@13 79
michael@13 80 =item I<root>B</man/man>I<N>B</>foo -> B<../>I<pkgdir>B</>barB</man/man>I<N>B</>foo
michael@13 81
michael@13 82 This activates the Unix manual page
michael@13 83 I<root>B</>I<pkgdir>B</>barB</man/man>I<N>B</>foo as
michael@13 84 I<root>B</man/man>I<N>B</>foo. It can be found by the man(1) tool
michael@13 85 by placing I<root>B</man> into the environment variable C<MANPATH>
michael@13 86 (B<MANPATH="..:>I<root>B</man:..">). Keep in mind that B<openpkg lsync>
michael@13 87 activates any files found in the B<man/manI<N>> sub-directory of the
michael@13 88 package, but the man(1) tool usually requires the filename scheme
michael@13 89 fooB<.>I<N> before it can find the file.
michael@13 90
michael@13 91 =item I<root>B</info/>foo -> B<../>I<pkgdir>B</>barB</info/>foo
michael@13 92
michael@13 93 This activates the GNU info page I<root>B</>I<pkgdir>B</>barB</info/>foo
michael@13 94 as I<root>B</info/>foo. It can be found by the info(1) and pinfo(1)
michael@13 95 tools by placing I<root>B</info> into the environment variable
michael@13 96 C<INFOPATH> (B<INFOPATH="..:>I<root>B</info:..">). Keep in mind that
michael@13 97 B<openpkg lsync> activates any files found in the B<info/> sub-directory of the
michael@13 98 package, but the info(1) and pinfo(1) tools usually require the filename
michael@13 99 scheme fooB<.info> before it can find the file.
michael@13 100
michael@13 101 =item I<root>B</include/>foo -> B<../>I<pkgdir>B</>barB</include/>foo
michael@13 102
michael@13 103 This activates the C header I<root>B</>I<pkgdir>B</>barB</include>/foo
michael@13 104 as I<root>B</include/>foo. It can be found by the C/C++ compilers
michael@13 105 by adding I<root>B</include> to their include search path (B<cc ..
michael@13 106 -I>I<root>B</include> B<...>). Keep in mind that B<openpkg lsync> activates any
michael@13 107 files found in the B<include/> sub-directory of the package, but the
michael@13 108 C/C++ compiler usually by convention use the filename scheme fooB<.h>.
michael@13 109
michael@13 110 =item I<root>B</lib/>foo -> B<../>I<pkgdir>B</>barB</lib/>foo
michael@13 111
michael@13 112 This activates the C library I<root>B</>I<pkgdir>B</>barB</lib>/foo
michael@13 113 as I<root>B</lib/>foo. It can be found by the C/C++ compilers (and
michael@13 114 the linker they use) by adding I<root>B</lib> to their library search
michael@13 115 path (B<cc .. -L>I<root>B</lib> B<...>). It can be found by the Unix
michael@13 116 Dynamic Loader by adding I<root>B</lib> to the environment variable
michael@13 117 C<LD_LIBRARY_PATH> (B<LD_LIBRARY_PATH="..:>I<root>B</lib:..">).
michael@13 118 Keep in mind that B<openpkg lsync> activates any files found in the B<lib/>
michael@13 119 sub-directory of the package, but the C/C++ compiler usually require the
michael@13 120 filename scheme B<lib>fooB<.a> and the Unix Dynamic Loader the filename
michael@13 121 scheme B<lib>fooB<.so> before they actually can use the file.
michael@13 122
michael@13 123 =back
michael@13 124
michael@13 125 It is obvious that more sub-directories in a package installation
michael@13 126 might exist -- for instance B<share/>, B<var/>, B<libexec/>, etc. But
michael@13 127 B<openpkg lsync> intentionally does not link files in those directories into
michael@13 128 corresponding directories of the access layer, because those files do
michael@13 129 not require that they are located in a global area in order to be used.
michael@13 130 So B<openpkg lsync> only creates the access layer for files where a common area
michael@13 131 is required for (easy) use.
michael@13 132
michael@13 133 =head1 SPECIAL FEATURES
michael@13 134
michael@13 135 There are two special features supported by B<openpkg lsync>:
michael@13 136
michael@13 137 =over 4
michael@13 138
michael@13 139 =item B<Run-Command Files>
michael@13 140
michael@13 141 B<openpkg lsync> on startup implicitly reads command line options from
michael@13 142 C<.lsyncrc> files. They are searched in all parent directories and in
michael@13 143 the callers home directory. Their contents is prepended to the list of
michael@13 144 given command line options.
michael@13 145
michael@13 146 =item B<Multiple Package Versions>
michael@13 147
michael@13 148 B<openpkg lsync> skips all directories under I<root>/I<pkgdir>/ which contain
michael@13 149 the pattern "-[0-9]" in their directory name. On the other hand,
michael@13 150 B<openpkg lsync> follows also symbolic links under I<root>/I<pkgdir>/.
michael@13 151 This can be used for installing multiple versions of a package and
michael@13 152 switching between them. For instance, if version 1.0 of package
michael@13 153 "foo" is installed into directory I<root>/I<pkgdir>/foo-1.0,
michael@13 154 version 1.1 into I<root>/I<pkgdir>/foo-1.1 and version 1.2 into
michael@13 155 I<root>/I<pkgdir>/foo-1.2, B<openpkg lsync> does skip all three. To enable
michael@13 156 version 1.1 one just creates a symbolic link I<root>/I<pkgdir>/foo
michael@13 157 pointing to foo-1.1. Then B<openpkg lsync> picks up the files in
michael@13 158 I<root>/I<pkgdir>/foo-1.1. If you want to temporarily upgrade to
michael@13 159 foo-1.2, all you have to do is to change the symlink pointing from
michael@13 160 foo-1.1 to foo-1.2.
michael@13 161
michael@13 162 =item B<Temporarily Deactivated Package>
michael@13 163
michael@13 164 One can deactivate a package "foo" by going to I<root>/I<pkgdir>/foo/
michael@13 165 and running "openpkg lsync --local --uninstall", of course. Alternatively
michael@13 166 one can set the sticky bit on the directory I<root>/I<pkgdir>/foo.
michael@13 167 Then B<openpkg lsync> also skips the package. Alternatively, assume
michael@13 168 package "foo" as a whole should not be deactivated, but its
michael@13 169 I<root>/I<pkgdir>/foo/lib directory (usually because this directory
michael@13 170 unfortunately contains non-library files), one just sets the sticky bit
michael@13 171 on I<root>/I<pkgdir>/foo/lib.
michael@13 172
michael@13 173 =back
michael@13 174
michael@13 175 =head1 OPTIONS
michael@13 176
michael@13 177 =over 4
michael@13 178
michael@13 179 =item B<--version>, B<-v>
michael@13 180
michael@13 181 Display program version information only.
michael@13 182
michael@13 183 =item B<--help>, B<-h>
michael@13 184
michael@13 185 Display program usage information only.
michael@13 186
michael@13 187 =item B<--init>, B<-i>
michael@13 188
michael@13 189 Create an initial access layer hierarchy under I<root>.
michael@13 190
michael@13 191 =item B<--nop>, B<-n>
michael@13 192
michael@13 193 No Operation -- causes B<openpkg lsync> to not perform any filesystem
michael@13 194 operations. In conjunction with B<--trace> you can at least see what
michael@13 195 would be executed.
michael@13 196
michael@13 197 =item B<--quiet>, B<-q>
michael@13 198
michael@13 199 Forces B<openpkg lsync> to perform the operations quietly, i.e., without any
michael@13 200 verbose messages.
michael@13 201
michael@13 202 =item B<--trace>, B<-t>
michael@13 203
michael@13 204 Forces B<openpkg lsync> to show what filesystem operations are performed.
michael@13 205
michael@13 206 =item B<--local>, B<-l>
michael@13 207
michael@13 208 This restricts the operations to a local package area. This option can
michael@13 209 only be used if you are physically staying below a package sub-directory
michael@13 210 under I<root>/I<pkgdir>/. For instance, when you are staying in
michael@13 211 I<root>/I<pkgdir>/bar or I<root>/I<pkgdir>/bar/bin and use B<--local>,
michael@13 212 all operations are restricted to the package "bar".
michael@13 213
michael@13 214 =item B<--uninstall>, B<-u>
michael@13 215
michael@13 216 This performs only package uninstallation operations, i.e., only
michael@13 217 symbolic links are removed. This can be used to completely empty the
michael@13 218 access layer. Additionally it is very useful in combination with
michael@13 219 B<--local> in order to uninstall a particular package without having to
michael@13 220 remove its files.
michael@13 221
michael@13 222 =item B<--root=>I<root>
michael@13 223
michael@13 224 Sets the root directory where the access layer and package subdirectory
michael@13 225 is located. The default can be determined by running C<openpkg lsync --help>
michael@13 226 (see section "Current configuration").
michael@13 227
michael@13 228 =item B<--pkgdir=>I<pkgdir>
michael@13 229
michael@13 230 Sets the sub-directory under the root directory where packages are
michael@13 231 located. The default can be determined by running C<openpkg lsync --help> (see
michael@13 232 section "Current configuration").
michael@13 233
michael@13 234 =item B<--subdirs=>I<subdirs>[,I<subdir>,...]
michael@13 235
michael@13 236 Sets one or more sub-directories of the access layer on which B<openpkg lsync>
michael@13 237 should act. The default can be determined by running C<openpkg lsync --help>
michael@13 238 (see section "Current configuration").
michael@13 239
michael@13 240 =back
michael@13 241
michael@13 242 =head1 RESULTS
michael@13 243
michael@13 244 This program uses the following return codes on exit: 0 (operation
michael@13 245 successful), 1 (system error), 2 (command line error) and 3 (other user
michael@13 246 error).
michael@13 247
michael@13 248 =head1 HISTORY
michael@13 249
michael@13 250 The idea of filesystem access layers consisting of symbolic links
michael@13 251 pointing to actual package installation areas is a rather old one. It
michael@13 252 dates back to the early days of Unix and was implemented many times over
michael@13 253 the last decades. One of many implementation was B<GenOPT>, written by
michael@13 254 Ralf S. Engelschall for sd&m GmbH & Co KG, Munich in 1992. The name
michael@13 255 indicates the programs purpose: to generate symbolic links in an access
michael@13 256 layer which was located under C</opt>. B<GenOPT> was very flexible, but
michael@13 257 hence also very complex. Because of lack of documentation it was never
michael@13 258 released and so only used at sd&m and on all machines which were under
michael@13 259 control of Ralf S. Engelschall.
michael@13 260
michael@13 261 For Cable & Wireless, Munich, the old B<GenOPT> principle was again
michael@13 262 needed to manage the C</cw/local> area on their servers. For this in
michael@13 263 November 2000 the functionality of B<GenOPT> was revised, heavily
michael@13 264 stripped down and finally implemented from scratch. The result is the
michael@13 265 current B<openpkg lsync>.
michael@13 266
michael@13 267 =head1 AUTHOR
michael@13 268
michael@13 269 Ralf S. Engelschall
michael@13 270 rse@engelschall.com
michael@13 271 www.engelschall.com
michael@13 272
michael@13 273 =cut
michael@13 274

mercurial