1 \documentclass[a4paper,
10pt
]{article
}
5 \title{store-extra: Useful Store admin and config applications
}
6 \author{Petter Reinholdtsen $<$pere@td.org.uit.no$>$
}
12 \section{Introduction
}
14 The
{\tt store-extra
} Store application is my collection of useful
15 Store admin and config scripts which is not part of the Store base
16 (
{\tt perl-internal
}). Most of it used to be part of smaller
17 applications, but I decided to collect it into one application
20 This is the collection of what used to be
{\tt store-pere
},
{\tt
21 env-config
},
{\tt mime-config
},
{\tt emacs-info
},
{\tt build-all
} and
22 some scripts from NTNUs
{\tt emacs
} application.
24 I did not write all these scripts. I have lost track of all the
25 authors, but some of them were written by Espen Skoglund, Bjørn
26 Stabell, Arne H. Juul, and more. If your credit is missing here,
29 \section{Compiling new applications and versions
}
31 The build-all scripts provides the simplest way to compile new
32 programs in store. It works best with source using GNU autoconf and
33 Perl modules. It has limited support for X imake source and normal
34 makefiles. If the application fails to compile using build-all, the
35 original method described in the original Store documentation must be
38 When everything works as it should, this sequence would give a
39 compiled version of a new application:
43 \item Make new application subdirectory in
{\tt /store/store/<master>/
}.
45 \item Fetch source and update
{\tt registration
} with source location.
46 FTP sites are better then HTTP sites. Replace version number with
47 {\tt \$version
} to allow automatic detection of new versions.
50 \begin{quote
}\begin{verbatim
}
51 echo 'Source: ftp://ftp.gnu.org/pub/gnu/gcc-$
{version
}.tar.gz' >> registration
52 \end{verbatim
}\end{quote
}
56 \item Unpack source in application subdirectory. Rename source
57 subdirectory to
{\tt src-<version>
}.
59 \item Check source to find out if there is a
{\tt configure
} script
60 (=buildtype GNU) or a
{\tt Makefile.PL
} file (=buildtype pm). If
61 not, build-all is likely to fail.
64 \item Create a file
{\tt buildinfo
} in the applicatio subdirectory
66 with the information required to get build-all to compile this
67 application. The absolute minimum file contains
{\tt appname
},
{\tt
68 version
} and
{\tt buildtype
}.
71 \begin{quote
}\begin{verbatim
}
75 \end{verbatim
}\end{quote
}
78 \item Run
{\tt build-all
[archs
]} in application subdirectory and
79 check the current compile status in the files
{\tt out.<arch>
} to
80 find out if everything works as planned.
83 \begin{quote
}\begin{verbatim
}
85 \end{verbatim
}\end{quote
}
88 \item If this was a perl module, run
{\tt pm-touch-compiled
} to make
89 sure platform dependent subdirectories are properly marked in Store.
91 \item Check content of ver-<version> to make sure everything looks OK.
93 \item Run
{\tt chkapp
} to make sure everything went OK.,
{\tt
94 register
} to insert and update the info on the application and to
97 \item Run
{\tt linkup
} and test if the program is working.
102 \section{Common environment settings
}
104 Two files are generated with the common environment settings,
{\tt
105 /store/etc/src.sh
} and
{\tt /store/etc/src.csh
}. One file for the
106 Bourne shell family (sh, ksh, zsh, bash, etc) and one for the C shell
107 family (csh, tcsh). These files are generated by
{\tt
108 /store/etc/internal/make-env.pl
} based on the content in
{\tt
109 /store/etc/ENV/ENV-*
}. They are regenerate every time the nightly
110 commands are being run.
112 The format is quite simple, with '\#' as the comment marker, and the
113 fields in the env lines being
114 'username;group;priority;type;variable=content.
119 # Set path, check if directories exists.
120 *:*:
1:p:PATH=/store/gnu/bin:/store/opt/*/bin
121 *:*:
2:p:PATH=/store/bin:/store/sbin
122 !
0:*:
5:p:PATH=/usr/games
124 # Include in path without checking for the directories
125 *:*:
1:n:XFILESEARCHPATH=/store/lib/X11/app-defaults/
%N
126 *:*:
9:n:XFILESEARCHPATH=/usr/local/lib/X11/
%L/app-defaults/%N
133 Username and group must be '*' or user or group id number. '!'
134 negates the test. In the example, this make sure user root (
0) do not
135 get /usr/games as part of the PATH.
137 The path environment type 'p' and 'n' will remove duplicate entries,
138 and only keep the highest priority entry. The single entry
139 environment 's' will only keep the highest priority entry. The
140 priorities is sorted as perl strings, '
12' having lower priority then
143 The 'p' env type content might use filename globbing, as shown with
144 {\tt /store/opt/*/bin
}.
146 If you are installing an application which requires special
147 environment settings, the best way to handle this is to use a small
148 shell wrapper to set the environment and then call the program.
149 Renaming the binaries from
{\tt file
} to
{\tt file.exe
} and making a
150 new shell script
{\tt file
} which sets the environment is the best
151 way. Only when this is no option, you should use the
152 etc/ENV/ENV-application files. I suggest naming the files en ENV/
153 after the application they belong to, i.e ENV-netscape for netscape
154 env settings and ENV-less for less env settings.
156 \section{MIME mailcap files
}
158 When installing MIME content handlers, one wants to make them
159 automatically available in mail programs and web browsers. This is
160 done by placing a file in
{\tt /store/etc/mailcaps/
}. The files are
161 named
{\tt mailca-<app>-<priority>
}, and looks like normal MIME
164 \begin{quote
}\begin{verbatim
}
165 audio/x-mpeg; /store/bin/mpg123
%s;
166 \end{verbatim
}\end{quote
}
168 Based on these files, a list of MIME content handlers are generated
169 into
{\tt /store/etc/mailcap
} by
{\tt
170 /store/etc/internal/make-mailcap.pl
}. The priorities are sorted as
173 \section{Emacs info and default.el files
}
175 \subsection{Emacs info directory
}
177 All emacs info files should be installed in
{\tt /store/info/
}. These
178 files can (and probably should) be compressed with
{\tt gzip
}. Based
179 on the content of this subdirectory, a emacs info directory file (
{\tt
180 /store/info/dir
}) is generated by
{\tt
181 /store/etc/internal/make-emacs-dir.pl
}. This program requires a
182 section like this in the info files:
184 \begin{quote
}\begin{verbatim
}
185 INFO-DIR-SECTION Programming
187 * Cpp: (cpp). The GNU C preprocessor.
189 \end{verbatim
}\end{quote
}
191 All emacs info and texinfo files should have a section like this. If
192 it is missing, send a patch to the author. When working with .texi
193 files, a section like this will make sure the resulting info files
194 will be included in the info/dir file:
196 \begin{quote
}\begin{verbatim
}
197 @dircategory Programming
199 * Cpp: (cpp). The GNU C preprocessor.
201 \end{verbatim
}\end{quote
}
203 \subsection{Emacs default.el
}
205 Generates
{\tt /store/lib/emacs/site-lisp/default.el
} and
{\tt
206 /store/share/emacs/site-lisp/default.el
} from
{\tt default.el-<app>
}
207 in the same directory.
209 \section{Netscape plugins
}
211 To make sure Netscape finds the installed plugins, they must be
212 installed in a common directory, and environment
{\tt
213 NPX
\_PLUGIN\_PATH} must be set to point to this directory. The
214 environment should be set in a wrapper shell to make sure it is always
215 set when netscape is running.
217 I propose using
{\tt /store/opt/ns-plugins/
} as this common directory.
218 I suggest naming the Netscape plugin applications with prefix '
{\tt
219 nsp-
}', to make it easier to track the different netscape plugins
222 \section{GIMP plugins
}
224 [I do not know enough about gimp to make a suggestion here.
]
226 \section{List of recently installed applications
}
228 To make it easier for the users to keep track of the applications
229 available in /store, the script
{\tt /store/etc/internal/news.pl
}
230 generates UNIX news files in
{\tt /store/news
}. These files can then
231 be accessed by news(
1) to get a list of recently installed
234 \section{Various tools
}
238 check-libtool-libs.pl findold.pl nightly-fix-suid.pl sourcewatch.pl
239 chkapps.pl fix-docdirs.pl prognews.pl usage.pl
240 collectusage.pl showusage.pl vusage.pl
242 compare-linktrees store-app-dependson
245 \section{Build-all -- parallel multiplatform autocompile
}
247 The buildall system consist of the following configuration files:
251 \item[\~
{}store/etc/master.conf
]
253 Site specific configuration (information about master store
256 \item[\~
{}store/etc/buildhosts
]
258 The list Store architectures to compile for, and the hosts to
259 compile the application for this architecture.
261 \item[\$appdir/buildinfo
]
263 The application specific information, located in the
264 application master directory.
268 The following programs are part of buildall:
272 \item[/store/bin/build-all
]
274 The program called when starting to compile. This must be run
275 in the application master directory.
277 \item[/store/etc/internal/buildsubs
]
279 Script called by build-all to do the work required.
281 \item[/store/bin/pm-touch-compiled
]
283 Perl module compile support script.
285 \item[/store/etc/internal/etc/pm-a-by-a
]
287 Mapping mellom store-arkitektur og Perl5 arkitekturnavn
291 \subsection{buildinfo variables
}
293 \section*
{References
}
295 Store documentation, http://www.pvv.org/\~
{}arnej/store/storedoc.html
297 Automatisk kompilering av Store-programmer på alle plattformer
299 ==============================================================
301 Petter Reinholdtsen <pere@td.org.uit.no>,
1999-
07-
27
303 IT-avdelingen bruker et system kalt 'build-all' hentet fra NTNU for
304 dette. Når det virker går kompilering mye raskere enn før. Når det
305 ikke virker gjøres kompilering som før. Kopi av NTNUs buildinfo filer
306 ligger i store-applikasjon build-all/ntnu-buildinfo/
308 For å autokompilere for flere arkitekturer lager du et /bin/sh script
309 'buildinfo' i applikasjonskatalogen på master, parallelt med fila
310 'registration', for å sette endel variabler. Deretter kjører du
311 'build-all'. Hvis alt gikk bra, har du etter en stund kompilert opp
312 applikasjonen for alle plattformer. Sjekk out.* for å se hvordan det
313 går med bygging av applikasjonen.
315 Når kompileringen er ferdig på alle plattformer (siste linje i out.*
316 er "...done"), så kjøres chkapp og register på vanlig måte.
318 Eksempelfil for GNU configure programmer:
324 Eksempelfil for Perl5 moduler:
326 appname=Net-Netmask.pm
330 Følgende variabler kan settes:
333 Navn på applikasjonen som skal genereres, dvs katalognavnet i
334 Master Store. Må settes, ingen default.
336 Versjon på applikasjonen som skal genereres. Må settes, ingen
339 Hvordan kompilering av applikasjonen skal gjøres. Må settes,
340 ingen default. Følgende er støttet:
343 GNU GNU Autoconf oppsett
344 pm Perl5 module, dvs applikasjon med 'Makefile.PL'
345 make ???. Forutsetter at konfigurering allerede er gjort.
348 Kan være blank. Default er '/store'.
350 Kan være blank. Parameter til configure for buildtype GNU.
351 Default er '--prefix=\$prefix'.
353 Kan være blank, da brukes confstring eller standard for buildtype
354 GNU ('./configure \$confstring').
356 Kan være blank. Parameter til make. Default er intet
359 Kan være blank. Parameter til make for a installere
360 applikasjonen. Default for X er 'install install.man', for
364 Kan være blank. Liste over applikasjoner som linkes henholdsvis
365 ned og opp fra linktreet før og etter installasjon.
366 Space-separert liste.
368 Kan være blank. Kommando som kjøres etter postinst på
369 maskinen er installasjonen ble gjennomført.
371 Liste over applikasjoner som skal linkes opp før kompilering.
372 Formatet er 'app versjon store', og flere applikasjoner skilles
373 med skråstrek(/). Eksempel:
374 linkupthis='glib
1.2.2/gtk
1.2.2'
376 Kan være blank. Hvilken kommando som brukes for å kjøre
377 kommandoer på andre maskiner. Default er 'ssh -x'.
379 Kan være blank. Nive-nivå for 'configure'- og
380 'make'-kommendoene. Default er 'nice -
15'
382 Kan være blank. Timeout-verdi for postinst. Default er
25.
384 Tilgjengelige shell-variabler i confcmd og postpostinstcmds:
386 SARCH Store-arkitektur
387 PMA Perl5 arkitekturnavn (for pm buildtype)
389 Buildall-systemet består av følgende filer:
392 Oppstart-scriptet som kjøres fra master-dir for applikasjonen
393 /store/etc/internal/buildsubs
394 Skriptet som gjør jobben
395 /store/etc/internal/etc/pm-a-by-a
396 Mapping mellom store-arkitektur og Perl5 arkitekturnavn
397 \$HOME/etc/buildhosts
398 Liste over hvilke maskiner de forskjellige arkitekturene
400 \$HOME/etc/master.conf
401 Informasjon om master-store.
403 Informasjon om applikasjonen som skal kompileres