From bceec08198198e2a21407528de76bcd756265e86 Mon Sep 17 00:00:00 2001 From: Manoj Srivastava Date: Thu, 16 Jun 2005 05:04:26 +0000 Subject: [PATCH] Initial revision Author: srivasta Date: 1998/09/07 07:45:57 Initial revision git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--patch-7 --- FSSTND-FAQ | 259 +++ debian-policy.desc | 19 + debian/RELEASED | 0 debian/changelog | 466 +++++ debian/control | 17 + debian/copyright | 56 + debian/dirs | 2 + debian/postinst | 22 + debian/prerm | 5 + debian/rules | 89 + fsstnd-1.2.ChangeLog | 39 + fsstnd-1.2.dvi.gz | Bin 0 -> 40260 bytes fsstnd-1.2.ps.gz | Bin 0 -> 52041 bytes fsstnd-1.2.txt.gz | Bin 0 -> 29705 bytes libc6-migration.txt | 263 +++ packaging-manual.desc | 19 + packaging.sgml | 3574 ++++++++++++++++++++++++++++++++ policy.sgml | 2591 +++++++++++++++++++++++ upgrading-checklist.html | 164 ++ virtual-package-names-list.txt | 135 ++ 20 files changed, 7720 insertions(+) create mode 100644 FSSTND-FAQ create mode 100644 debian-policy.desc create mode 100644 debian/RELEASED create mode 100644 debian/changelog create mode 100644 debian/control create mode 100644 debian/copyright create mode 100644 debian/dirs create mode 100644 debian/postinst create mode 100644 debian/prerm create mode 100755 debian/rules create mode 100644 fsstnd-1.2.ChangeLog create mode 100644 fsstnd-1.2.dvi.gz create mode 100644 fsstnd-1.2.ps.gz create mode 100644 fsstnd-1.2.txt.gz create mode 100644 libc6-migration.txt create mode 100644 packaging-manual.desc create mode 100644 packaging.sgml create mode 100644 policy.sgml create mode 100644 upgrading-checklist.html create mode 100644 virtual-package-names-list.txt diff --git a/FSSTND-FAQ b/FSSTND-FAQ new file mode 100644 index 0000000..e871fc0 --- /dev/null +++ b/FSSTND-FAQ @@ -0,0 +1,259 @@ +This is a collection of Frequently Asked Questions (and answers!) +about the Linux FSSTND project and document. It was composed by Ian +McCloghrie . Questions, corrections, clarifications, +etc. about this FAQ should be directed to him. + +Sun Oct 9 22:55:25 PDT 1994 + +Note: This FAQ is wrtten by me, personally, as an attempt to help out +the FSSTND project. This FAQ reflects my personal views and, while I +am a member of the FSSTND project, should not be construed as +necessarily reflecting the views of everyone on the project. + + +========= General Questions ========== + + +Q) Who wrote the FSSTND, and where can I get in contact with them? + +A) The FSSTND is a consensus effort of many Linux activists; the main +arm of their discussion takes place on the FSSTND mailing list. +The principal co-ordinator is Daniel Quinlan +Any questions you may have regarding the standard should be directed +to him or to any of the contributors listed in the FSSTND document or +this FAQ. + +The FSSTND discussion mailing list is "linux-fsstnd@ucsd.edu"; if you +wish to participate in future expansion of the standard, you can +subscribe to this list by sending mail to "listserv@ucsd.edu", with the +body of "add linux-fsstnd". + + +Q) What's the current status of the FSSTND? + +A) As of this writing, (Oct 9, 1994), Linux FSSTND 1.2 has been +released as an interim draft, and is available for anonymous FTP +from tsx-11.mit.edu in /pub/linux/docs/linux-standards/fsstnd. +PostScript, dvi, and ascii text versions are available. + +Due to the fact that a significant number of Linux developers are +making use of standard drafts that came after the first version (back +in February), the decision was made to issue an interim version in +order to ensure that everyone is working from the same foundation. + + +Q) Why 'FSSTND' anyway? That's a horrible abbreviation. + +A) Yes, 'FSSTND' is a horrible abbreviation of "Filesystem Standard". +Unfortunately, that's the name that was given to the initial channel +of the niksula.hut.fi mailing list, and it's kinda stuck. Changing it +would create more confusion than it's really worth. + + +Q) I've got a great new idea for how to organize the filesystem; +why don't we... + +A) If you really think you've got something revolutionary, by all +means, we'd love to see it. In practice, a lot of "great new" ideas +have been raised (and dropped, for one reason or another) on the +mailing list already. As such, we suggest you send mail to one of the +contributors privately first, and get his/her reaction to it, before +making a general proposal. + + +Q) Why did you do it *THIS* way? Why not do what Sun did and... + +A) The FSSTND draws ideas from POSIX, 4.4BSD, SVR4, SunOS 4, MCC, +Slackware, SLS, (in no particular order) and many other systems. We +have not followed any one operating system layout in entirety. +Instead we have tried to take the best of each filesystem layout and +combine them into a homogenous whole, well suited to the needs of +Linux users everywhere. In some cases, we may not have been +completely successful; however, we think we've done a fairly decent +job. + + +Q) You *&^% idiots, don't you know that foo goes in /bin, not in /usr/bin? + +A) Think about it. Does foo *really* need to go on the root +partition? Constructive suggestions are welcomed. Flames are not. + +We have tried to decide upon a set of binaries that is an effective +compromised between functionality and space restrictions. The root +partition needs to contain enough functionality to boot the system, +mount the /usr partition, and to enable a systems administrator to +repair things on /usr if something goes wrong. If you have a local +boot-time system that absolutely requires other binaries to be used +in the mounting of /usr, the suggested solution is to move them to +/bin and to make a symbolic link from /usr/bin/foo to /bin/foo. + + +Q) Does the fact that Daniel Quinlan now works for Yggdrasil affect +his coordination of the FSSTND? + +A) In short, no. In a bit more length, no, except for the fact that +he's now even more intimately familiar with the problems involved +in creating a distribution. (well, and that he's earning money and +can afford to buy food to eat, so has energy to spare worrying about +things like which directory cpio belongs in) + +FSSTND is not distribution-specific, the fact that the coordinator is +employed by one distribution-provider does not affect this fact. Yggdrasil +does not have any special connection to FSSTND, and vice versa. +To simplify things, Dan would appreciate it if you could direct FSSTND- +related email to . + + +========== Specific Questions ========== + + +Q) The distinction between the root partition and /usr is that the +root is used for files that are 'essential'. What constitutes +'essential'? + +A) essential to clean, create, prepare, check, find and mount other +filesystems (possibly on remote machines). There are other definitions, +but this is a general definition that most people will at least +incorporate into their own. + + +Q) I like to have a small root partition (possibly with multiple +copies, so I can get the system back up when one of them crashes), +and I like to stuff everything else into one big partition (especially +since I only have one free). So, can /var be a symlink to /usr? + +A) Making the /var hierarchy a part of a /usr filesystem is +preferable to making /var a part of the root filesystem when /var +cannot be made a separate partition. + +This is preferable because it is easier to separate /var and /usr +at some point in the future, if you buy a second disk. The usual way +of doing this to make /var a symblink link to /usr/var. + + +Q) Why is networking spread out across the filesystem in 4 separate +directories instead of all being nicely put in /usr/inet? + +A) It is the opinion of the FSSTND project (and, in fact, of much of +the UNIX community in general) that networking is not an "optional +package" in the traditional sense, but rather an integrated part oF +the operating system. Binaries such as telnet, ftp, and ping have +more similiarity to standard unix utilities such as grep, sed, and vi +than to applications like emacs or WordStar. As such, they are +spread across /bin, /sbin, /usr/bin, and /usr/sbin, depending upon +their use. + + +Q) I'm running a HUGE network with 10 different platforms and 20 +different OS's. I *need* to share things. Why isn't there a +/usr/share? + +A) At the moment, Linux is only really available for the +PC-architecture 80386 machines. (although this may change soon with +Amiga systems). There is no single existing "cross-platform" standard +for /usr/share; those that do exist have usually been come up with by +a single vendor wanting to share certain files between their OS +running on multiple hardware platforms. There are many problems +involved in the sharing of files, maybe obvious sharable files that +are, upon closer examination, not sharable at all. (For example, +/usr/man could be thought completely sharable, yet some pages (such as +fsck.1) are completely different from any other UNIX-like operating +system). + +/usr/share would be nice, yes, and we plan to include something like +this in a future version of the FSSTND. However, until such a time +as an implementation can actually be tested, no specifications will be +released. Anything in /usr/share will be "pointed to" by the use of +symlinks from other areas in the filesystem, such as /usr/man, +/usr/lib/, etc. Applications should use these locations +when they reference files, not the /usr/share location, as this may +change. Things like OSI have shown the problems with standards +specified without a real clue as to how they'd be implemented. + + +Q) Why are there so many/so few symbolic links in the filesytem? +Couldn't we make it easier to understand/more orthogonal by +removing/adding some links? + +A) In general, we've tried to minimize the number of symbolic links +present in the FSSTND. The symlinks that are present in the document +are the ones we considered essential to maintaining a properly +orthogonal, and yet still somewhat compatible, filesystem layout. +/lib/cpp and /usr/lib/sendmail are symbolic links kept for +compatiblity reasons. + + +Q) What about statically linked binaries? Shouldn't we have a +statically linked copy of mount, unmount, sh, cp, mv, vi, emacs, gcc, +X11R5, and WABI in /sbin? + +A) Statically linked binaries are a local issue. Most users, those +with home systems with small amounts of memory and disk and a single +user on console, do not have any need for any statically linked +binaries (with the possible exception of ln, sync, and/or ldconfig, to +fix shared library problems). Some larger sites, with more disk to +spare, may wish to install backup, statically-linked versions of some +applications. If you have the need and space to do this, go right +ahead, we're not stopping you. But we don't require any, because +(we feel) that most people don't need them. Dynamically linked +versions should still be available, for regular usage, however. + + +Q) Why does X11 get its own directory tree when there aren't any +other such "packages" in the FSSTND? Why not spread it out over +/usr/bin/X11, /usr/lib/X11, etc. + +A) X11 is just about the largest 'package' in common use on Linux +systems. It resides in /usr/X386 as this is the directory name choice +of the XFree86 developers, to protect against namespace conflicts with +other X11 packages on any of the dozen or so PC-unix platforms they +support. The symbolic links in /usr/bin/X11, /usr/lib/X11 and +/usr/include/X11 are for user's convenience, these are the closest +things that exist to "standard" locations for the X11 files. + + +Q) Why isn't there a package format laid out in the FSSTND? + +A) Many proposals have been discussed for package layouts on the +fsstnd mailing list. As yet, no consensus has been reached about +which (if any) of these proposals is best. Work continues, and there +will probably be mention of 'packages' in version 1.1. + + +Q) What about /usr/local/bin/X11? Should I use this for local X11 +programs? Or is /usr/local/X11/bin better? + +A) The standard doesn't specify; we feel that the contents of /usr/local +are exactly that, local, and so we try to specify as little as +possible about it. Put them wherever you want. Personally, I use +/usr/local/bin/X11. However, since xmkmf doesn't seem to like placing +files into anywhere other than where the existing X files are +(ie, /usr/X386/*), my libs for local apps usually end up being in +/usr/X386. Ugly, yes, but not worth (to me) the effort of trying to +move them. Your mileage may vary. + + +Q) Why doesn't the standard specify the system-level users/groups and +proper ownerships/permissions/setuid bits for everything? + +A) We feel that this is, primarily, a local issue. Many sites +have their own local user-id/group-id setup, and linux boxes will +have to be integrated with those. What's more, there is very little +gain from standardizing these across all linux machines, as it +typically is not essential to allow binary distributions. + + +Q) Why not just symlink /bin to /usr/bin the way Sun, SVR4, and a few +others do? + +A) This has several technical problems, aside from the fact that many +consider it ugly. First, it requires placing all the utilites necessary +to mount /usr into /sbin, and either making copies of them in /usr/bin +or having every user put /sbin into their $PATH. Second, if /lib is +symlinked to /usr/lib in the same way, it requires statically linking +all the binaries in /sbin. This results in /sbin taking up more space +on the root partition, for a great reduction in functionality, thus +increasing the number of cases in which one has to go dig out a +boot/root floppy instead of just booting the hard disk in single-user +mode. + diff --git a/debian-policy.desc b/debian-policy.desc new file mode 100644 index 0000000..90640f4 --- /dev/null +++ b/debian-policy.desc @@ -0,0 +1,19 @@ +Document: debian-policy +Title: Debian Policy Manual +Author: Ian Jackson and Christian Schwarz +Abstract: This manual describes the policy requirements for the Debian + GNU/Linux distribution. This includes the structure and contents of + the Debian archive, several design issues of the operating system, as + well as technical requirements that each package must satisfy to be + included in the distribution. +Section: Apps/Programming + +Format: debiandoc-sgml +Files: /usr/doc/debian-policy/policy.sgml.gz + +Format: text +Files: /usr/doc/debian-policy/policy.text.gz + +Format: HTML +Index: /usr/doc/debian-policy/policy.html/index.html +Files: /usr/doc/debian-policy/policy.html/*.html diff --git a/debian/RELEASED b/debian/RELEASED new file mode 100644 index 0000000..e69de29 diff --git a/debian/changelog b/debian/changelog new file mode 100644 index 0000000..3c2812b --- /dev/null +++ b/debian/changelog @@ -0,0 +1,466 @@ +debian-policy (2.4.1.4) unstable; urgency=low + + * New Maintainer + + -- Philip Hands Sat, 5 Sep 1998 02:41:35 +0100 + +debian-policy (2.4.1.3) unstable; urgency=low + + * New maintainer (with changes from Adam P. Harris' proposed NMU) + * policy.sgml: some awkward phrasings fixed (closes Bug#22006) + * policy.sgml: s/depreciated/deprecated (closes Bug#21831) + * debian/control: added conflict doc-base (<< 0.6), which I still am not + sure why we need this but hey (closes Bug#21554) + * policy.sgml: use new tag where appropriate + * policy.sgml, debian/control: always dynamically self reference the + current version of policy, that is, do not hard code policy revision + or date anywhere + * debian/rules: use dpkg-gencontrol -isp + * bugs fixed in some unknown previous version (closes Bug#23177) + + -- Philip Hands Tue, 11 Aug 1998 09:54:17 +0100 + +debian-policy (2.4.1.2) frozen unstable; urgency=low + + * non-maintainer release + * rebuild package to fix truncated Chapter 3 (Bug#23408, not marked as + important but should be, since a gaping hole in policy is very + annoying.) + * bumped version of policy, within the document, to this version number, + but not the date, indicating nothing really changed since then + * no content changes + * debian/rules: clean is a little cleaner + + -- Adam P. Harris Tue, 16 Jun 1998 03:15:22 -0400 + +debian-policy (2.4.1.1) frozen unstable; urgency=low + + * Orphaned package + + -- Christian Schwarz Thu, 14 May 1998 21:54:50 +0200 + +debian-policy (2.4.1.0) frozen unstable; urgency=low + + * Changes to the Debian Policy Manual: + + - Updated section 3.1.2 Site-specific programs + and section 3.8 Keyboard configuration: + + improved wording (fixes:bug#20129) + + - Updated section 2.1.7 Subsections: + + fixed typos (fixes:bug#18145) + + - Updated section 3.3.5 Symbolic links: + + symbolic links within a toplevel directory should be relative, + symbolic links between toplevel directories should be absolute + (cf., Policy Weekly Issue#6, topic 2) + + - Updated section 3.4 System run levels: + + Intro: mention /etc/rcS.d (links to boot time scripts) + + Notes: include rationale why /etc/init.d scripts have to be tagged + as conffiles (fixes:bug#16199) + + Example: changed example init.d script to handle force-reload + and restart options and to comply with the console message + standard (fixes:bug#19216) + + - Updated section 4.8 Emacs lisp programs: + + Replaced old section about lisp programs with a reference to + the file debian-emacs-policy.gz, installed by the emacsen-common + package. + + - Updated section 4.9 Games: + + manpages for games should be installed in /usr/man/man6 + (cf., Policy Weekly Issue#6, topic 3) + + - Removed one example reference to the current standards version + - Include manual's date as plain text in the .sgml source so that + a recompiled manual uses the same release date + + * Changes to the authoritative list of virtual package names: + - Removed obsolete virtual package `emacs' + + * New version numbering scheme: + + - The version numbers are independent of dpkg now, but all policy + manuals (the Debian Policy Manual, the Debian Packaging Manual, and + the Debian Developer's Reference) share the same version numbering + scheme. + + - The first three digits of the version number specify the + `Standards-Version.' This number is incremented with each policy + change. The fourth digit represents the `patch-level,' which may + differ between the manuals. + + If only the patch-level digit is incremented, no changes in policy + have been made, except bug fixes and clarifications. Packages only + have to specify the first three digits of the version number in the + `Standards-Version' field of their source packages. + + * Packaging changes: + + - Uploaded to frozen and unstable. This is a documentation-only + package and the changes to the manual are relevant for hamm. + + - Fixed FSF's address in copyright file (detected by Lintian) + + -- Christian Schwarz Tue, 14 Apr 1998 10:08:09 +0200 + +debian-policy (2.4.0.0) unstable; urgency=low + + * Changes to the Debian Policy Manual: + + - Updated section 3.3.4 Scripts: + + /bin/sh may be any POSIX compatible shell + + scripts including bashisms have to specify /bin/bash as + interpreter + + scripts which create files in world-writable directories + (e.g., in /tmp) should use tempfile or mktemp for creating + the directory + + - Updated section 3.3.5 Symbolic Links: + + symbolic links referencing compressed files must have the same + file extension as the referenced file + + - Updated section 3.3.6 Device files: + + /dev/tty* serial devices should be used instead of /dev/cu* + + - Updated section 3.4.2 Writing the scripts [in /etc/init.d]: + + all /etc/init.d scripts have to provide the following options: + start, stop, restart, force-reload + + the reload option is optional and must never stop and restart + the service + + - Updated section 3.5 Cron jobs: + + cron jobs that need to be executed more often than daily should + be installed into /etc/cron.d + + - Updated section 3.7 Menus: + + removed section about how to register HTML docs to `menu' + (the corresponding section in 4.4, Web servers and applications, + has been removed in policy 2.2.0.0 already, so this one was + obsolete) + + - New section 3.8 Keyboard configuration: + + details about how the backspace and delete keys should be + handled + + - New section 3.9 Environment variables: + + no program must depend on environment variables to get a + reasonable default configuration + + - New section 4.6 News system configuration: + + /etc/news/organization and /etc/news/server should be supported + by all news servers and clients + + - Updated section 4.7 Programs for the X Windows system: + + programs requiring a non-free Motif library should be provided + as foo-smotif and foo-dmotif package + + if lesstif works reliably for such program, it should be linked + against lesstif and not against a non-free Motif library + + - Updated section 4.9 Games: + + games for X Windows have to be installed in /usr/games, just as + non-X games + + - Lots of typos fixed (thanks to Ray Dassen for the patch!) + + * Changes to the authoritative list of virtual package names: + - added `libc-dev' and `emacsen' + + * Merged `/usr/doc/debian-policy/changelog-policy.gz' into this + changelog file + + * Included `Policy checklist for upgrading your packages' from the + Policy Home Page as /usr/doc/debian-policy/upgrading-checklist.text.gz + + * Added support for doc-base to register the Policy Manual to the + online documentation systems dwww and dhelp (fixes:#15710) + + * Upgraded to standards version 2.4.0.0 (no changes) + + -- Christian Schwarz Fri, 30 Jan 1998 21:58:25 +0100 + +debian-policy (2.3.0.1) unstable; urgency=low + + * Changes in the Debian Policy Manual: + - X library package is now called xlib6g + * Changes in the authoritative list of virtual package names: + - Added emacs, c-compiler, fortran77-compiler, lambdamoo-core, + lambdamoo-server + * Conflict with old dpkg-dev version that included policy manual + (fixes #13790) + * Removed `tentative-opt-draft' from package since people considered + the draft official policy (which is not the case) + * Don't use debstd anymore + + -- Christian Schwarz Tue, 21 Oct 1997 23:03:52 +0200 + +debian-policy (2.3.0.0) unstable; urgency=low + + * Changes in the Debian Policy Manual: + - reworked chapter `The Debian Archive' to cover new + contrib/non-free policy + - call "contrib" and "non-free" a `section' (not `distribution') + - refer to license files (GPL, LGPL, etc.) as uncompressed files + - changed `/etc/news/server' into `/etc/nntpserver' in example of + maintainer scripts (fixes #11517) + - new section about `Daemons' + - updated section about `Configuration files' + - MUAs and MTAs have to use liblockfile + - fixed typos and grammatical errors + * Changes in the authoritative list of virtual package names: + - renamed tcl/tk virtual package names to `tclsh' and `wish' + * Paper about libc6 migration: + - fixed typos (fixes #11641), thanks to James Troup for the patch! + * SGML source code included in package + * don't use `2-up' style for PostScript version (fixes #11095) + + -- Christian Schwarz Mon, 2 Sep 1997 00:54:31 +0200 + +debian-policy (2.2.0.0) unstable; urgency=low + + * Changes in the Debian Policy Manual: + - completely reworked structure + - moved sections about new maintainers, upload procedure, interim + releases, and mailing lists into the Developers Reference Manual + - moved a few (small) sections into the Debian Packaging Manual + - removed all those ugly footnotes + - new example for "reload" in section about console messages + - mention Artistic License (fixes #9793) + - don't mention dpkg's version number in Policy Manual + - rewrote abstract and section introductions + - mention "orphaned packages" + - maintainer is responsible for a package license to comply with the + distributions' policy + - putting a package into base section requires discussion on debian-devel + - rewrote sections about "pre-depends", "essential" and, "base" packages + - added note that non-us' maintainers have to live outside the US + - added crypto-hook statement (fixes #7257) + - added section about arch spec strings + - rewrote section about "Site specific programs" (/usr/local) + - included Ian's suggestions for user IDs + - added section about "menus" + - removed section about "web menus" since this will be superseded with + the new documentation policy soon + - incorporated "Debian Free Software Guidelines" (fixes #9024) + - removed note that linking with -g produces large a.out binary (fixes + #11008) + - added section about editors and pagers + - added note about Package priorities and dependencies + - added section about cron jobs (fixes #8814) + - added section about device files + - don't install shared libraries as executable (fixes #7129) + - app-defaults files may not be conffiles (cf. #2717) + - lots of minor changes not worth mentioning here (typos, formulations, + etc.) + * Changes in the authoritative list of virtual package names + - Removed obsolete virtual packages: xR6shlib, xlibraries, + compress, emacs, sgmls, inews, gs_x, gs_svga, gs_both, xpmR6 + - Added new section about obsolete names + * Added Helmut Geyer's paper about libc5-libc6 migration + * Fixed package's description + + -- Christian Schwarz Sun, 13 Jul 1997 13:25:51 +0200 + +debian-policy (2.1.3.3) frozen unstable; urgency=low + + * Mention Artistic License in section 2.5 (bug #9755) + + -- Christian Schwarz Wed, 14 May 1997 16:53:15 +0200 + +debian-policy (2.1.3.2) frozen unstable; urgency=low + + * Fixed an email address, an URL, and several typos in chapter 6 (#9358) + * Added new virtual package "wordlist" to list (requested by Joey Hess) + * Changed wording in section about "non-free" packages as suggested + by Kai Henningsen (#7076) + + -- Christian Schwarz Mon, 5 May 1997 20:05:39 +0200 + +debian-policy (2.1.3.1) frozen unstable; urgency=low + + * Fixed bug in chapter 7: `-ur' should read `-us' (#8874) + * Fixed bug in chapter 7: `-rwhatever' also needed for rebuild (#8874) + * Create a PS and HTML version of the Policy Manual and upload it + "byhand". + * Install virtual-package-names-list.text in /usr/doc/debian-policy + and upload it "byhand" too. + + -- Christian Schwarz Tue, 29 Apr 1997 18:02:14 +0200 + +debian-policy (2.1.3.0) unstable; urgency=low + + * Initial Release. + * New Policy Manager: Christian Schwarz + * Added section 2.4 about the "non-us" distribution. + * Added section 3.1.1 about the "Package" field in the control file. + * Added section 3.2.1 about "Binaries": two programs with different + functionality must not have the same name. + * Changed headline of section 3.2.6 into "Debian changelog and upstream + changelog" as suggested by Santiago Vila Doncel . + * Added log-rotating example to section 3.2.9 that tests with `-sf', + as suggested by Boris D. Beletsky . + * Added section 3.13: "Webstandard 3.0" by Christoph Lameter. + * Added section 3.14: "Standard for Console Messages" by Christian Schwarz. + * Split section 4.1 into 4.1.1 (Options for binaries) and 4.1.2 (Options + for libraries) + * Added note to 4.1.2: Libraries should be compiled with `-D_REENTRANT' + to make them compatible with LinuxThreads, by Rob Browning + . + * Added note to 4.1.2: Libraries should be stripped with + "strip --strip-unneeded", by Guy Maor . + * Section 5.2: Policy changelog is now + "/usr/doc/debian-policy/changelog-policy.gz". This fixes bug #6130. + * Section 6.2 renamed to "Uploading your first Debian package". This + fixes bug #6130. + + -- Christian Schwarz Sat, 15 Mar 1997 18:08:56 +0100 + +debian-manuals (2.1.2.2) frozen unstable; + + * Fixed even more typographical and grammatical errors in Policy and + Programmer's manual + * Corrected the contact email addresses again. + * Added a paragraph to Policy 6.3 on taking over an old package (Guy Maor) + * Added a paragraph to Programmer 4.2.14 on listing distributions to load + a package into. (Guy Maor) + * Further clarification of use of absolute pathnames in scripts in + Programmer 6.1. + + -- David Morris Tue, 3 Dec 1996 23:28:04 -0600 + +debian-manuals (2.1.2.1) frozen unstable; + + * Many editorial and formatting revisions with suggestions from Ian Jackson, + Guy Maor and others + * correction of chiark address in Policy 6.2 + * footnote in Programmers chapter 2 pointing to deb(5) manpage for + description of deb file format. + * addition of more dpkg examples in Programmer chapter 2 + * Replace paragraph in Policy 4.1 outlining compiling parameters for + shared libraries. + * Added paragraph in Programmer 6.1 on paths in maintainer scripts + (Bug #2481) + * Cleaned up language and formatting of Programmer's 12.2, shlibs + * Corrected contact addresses for listmaster and override-change + + -- David Morris Wed, 27 Nov 1996 08:17:16 -0600 + +debian-manuals (2.1.2.0) frozen unstable; + + * Mostly editorial changes in Policy Manual. + * Added summary of distribution criteria to Introduction + * Added section headings for copyright criteria + * Fixed typos (Bugs #4485, #4622) + * Added paragraph in Compilation Options related to use of shared and + static libraries. (Bug #5299) + * Paragraph added about where to find PGP and other export restricted + packages in section on Procedure + * Change in List administrator and in the contact address for becoming + a package maintainer + * A paragraph added related to who to contact for package maintainer changes. + * Changed where to send upload announcements: uploads destined for unstable, + frozen, or experimental go to debian-devel-changes. + + * Made some mostly editorial changes to Programmers Manual. + * Added a recommendation to debmake in Introduction. + * A further interpretation of the various Distributions is added with + the intent of helping people decide which one to choose. (section 4.2.14) + * Section 12 on Shared Libraries expanded with further technical information + on various shlib files + * Section in 2.2 on format of shlib file moved to new subsection within 12. + * Paragraph on adding a symlink without version number added to Shared + Library Section (Guy Maor, Bug #5299) + + -- David Morris Fri, 22 Nov 1996 23:41:39 -0600 + +debian-manuals (2.1.1.0) unstable; + + * Hard links are forbidden in source packages (they didn't work anyway, + and can't easily be made to work reliably). + * Do not use dpkg-divert or update-alternatives without consultation. + + * Do not need to declare dependencies on Essential packages. + * Restrictions on Pre-Depends stated in policy manual. + * debian/substvars file is now almost always auto-generated. + * Shared libraries must be installed stripped. + * Essential and Pre-Depends put together in policy manual. + + * Explained component-wise (file-wise) vs. package-wise dependencies. + + -- Ian Jackson Thu, 12 Sep 1996 01:00:41 +0100 + +debian-manuals (2.1.0.0) unstable; + + * Upstream changelog must be installed too (was just recommended). + + * Modification to use dpkg-shlibdeps added to conversion instructions. + * Packages which are buggy and orphaned but which are preserved for + compatibility go in contrib. + + * Programmers' manual source package section refers to conversion + instructions in policy manual. + * Make it clear that recommending a non-free or contrib package puts a + package in contrib. + + -- Ian Jackson Sun, 1 Sep 1996 17:47:18 +0100 + +debian-manuals (2.0.1.0) unstable; + + * varargs.h and libtermcap are obsolete - use stdarg.h and ncurses. + * Shared library link/library ordering corrected (aargh). + * When to byte-compile Elisp files. + * Missing final newlines not represented by dpkg-source. + + * Must post upload announcements to debian-changes. + * Moved some sections into new `configuring and building' chapter. + * Typo fixes. + + -- Ian Jackson Sat, 31 Aug 1996 20:07:22 +0100 + +debian-manuals (2.0.0.0) unstable; + + * Footnote added OK'ing copyrights which require name changes. + * More detail about changelog format names. + + * Problematic licence restrictions are formatted as lists. + * Mentioned 822-date utility as way to generate RFC822 format dates. + * Typos corrected. + * Released. + + -- Ian Jackson Mon, 26 Aug 1996 14:27:34 +0100 + +debian-manuals (0.2.1.1) unstable; + + * Can't overwrite directories in one package with files in another. + + -- Ian Jackson Sat, 24 Aug 1996 18:44:54 +0100 + +debian-manuals (0.2.1.0) unstable; + + * Policy says when and how to include original source in upload. + + * Need -sa on dpkg-genchanges/dpkg-buildpackage when converting. + + * Use minor patchlevel for meaning changes which don't affect packages. + * More verbosity about netiquette. + * Reorganised participation and upload policy: merged with mailing lists. + + -- Ian Jackson Fri, 23 Aug 1996 12:48:09 +0100 + +debian-manuals (0.2.0.1) experimental; + + * Said that system administrators' manual does not exist. + + -- Ian Jackson Fri, 23 Aug 1996 04:05:36 +0100 + +debian-manuals (0.2.0.0) experimental; + + * Draft releases. + + -- Ian Jackson Wed, 21 Aug 1996 15:07:53 +0100 + +Local variables: +mode: debian-changelog +add-log-mailing-address: "phil@hands.com" +End: diff --git a/debian/control b/debian/control new file mode 100644 index 0000000..51eba22 --- /dev/null +++ b/debian/control @@ -0,0 +1,17 @@ +Source: debian-policy +Section: doc +Priority: extra +Maintainer: Debian Policy List +Standards-Version: ${debian-policy:Version} + +Package: debian-policy +Architecture: all +Suggests: doc-base +Conflicts: dpkg-dev (<< 1.4.0.9), doc-base (<< 0.6) +Description: Debian Policy Manual and related documents + This package contains: + - Debian Policy Manual + - Linux Filesystem Structure (FSSTND) + - Authoritative list of virtual package names + - Paper about libc6 migration + - Policy checklist for upgrading your packages diff --git a/debian/copyright b/debian/copyright new file mode 100644 index 0000000..ed01efb --- /dev/null +++ b/debian/copyright @@ -0,0 +1,56 @@ + +This is the Debian package of Debian Policy Manual, the Linux +Filesystem Standard and related documents. It was assembled by +Christian Schwarz . + +------------------------------------------------------------------------------ +Copyright of the Debian Policy Manual: + +Copyright ©1996 Ian Jackson. + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +This is distributed in the hope that it will be useful, but without +any warranty; without even the implied warranty of merchantability or +fitness for a particular purpose. See the GNU General Public License +for more details. + +You should have received a copy of the GNU General Public License with +your Debian GNU/Linux system, in /usr/doc/copyright/GPL, or with the +dpkg source package as the file COPYING. If not, write to the Free +Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA +02111-1307, USA. + +------------------------------------------------------------------------------ +Copyright of the Linux Filesystem Standard (FSSTND). + + +Copyright (C) 1994, 1995 Daniel Quinlan + +Permission is granted to copy and distribute verbatim copies of this +standard provided the copyright and this permission notice are +preserved on all copies. + +Permission is granted for FSSTND contributors and participants to copy +and distribute modified versions of this standard under the conditions +for verbatim copying for purposes of filesystem standardization +activities only, and subject to those restrictions listed below. + +The following restrictions apply to reproducing or transmitting the +document in any form: + + o All copies or portions thereof must identify the document's title + and section, and must be accompanied by this entire notice in a + prominent location. + + o No portion of this document may be redistributed in any modified or + abridged form without the prior approval of the FSSTND coordinator. + +Any entities seeking permission to distribute any material derived +from this document (other than verbatim copies) must contact the +FSSTND coordinator for the appropriate license. + +-------------------------------------------------------------------------- diff --git a/debian/dirs b/debian/dirs new file mode 100644 index 0000000..21c85a6 --- /dev/null +++ b/debian/dirs @@ -0,0 +1,2 @@ +usr/doc/debian-policy/fsstnd +usr/share/doc-base diff --git a/debian/postinst b/debian/postinst new file mode 100644 index 0000000..3cc6f11 --- /dev/null +++ b/debian/postinst @@ -0,0 +1,22 @@ +#!/bin/sh + +set -e + +case "$1" in + configure) + # continue below + ;; + + abort-upgrade|abort-remove|abort-deconfigure) + exit 0 + ;; + + *) + echo "postinst called with unknown argument \`$1'" >&2 + exit 0 + ;; +esac + +if [ -x /usr/sbin/install-docs ]; then + /usr/sbin/install-docs -i /usr/share/doc-base/debian-policy +fi diff --git a/debian/prerm b/debian/prerm new file mode 100644 index 0000000..aeed835 --- /dev/null +++ b/debian/prerm @@ -0,0 +1,5 @@ +#!/bin/sh + +if [ -x /usr/sbin/install-docs ]; then + /usr/sbin/install-docs -r debian-policy +fi diff --git a/debian/rules b/debian/rules new file mode 100755 index 0000000..f1817cd --- /dev/null +++ b/debian/rules @@ -0,0 +1,89 @@ +#!/usr/bin/make -f + +DEB_VERSION := $(shell LC_ALL=C dpkg-parsechangelog | grep ^Version: | sed 's/^Version: *//') +DATE := $(shell date +"%Y-%m-%d") + +build: + $(checkdir) + rm -f version.ent + echo "" >> version.ent + echo "" >> version.ent + nsgmls -gues policy.sgml # check SGML syntax + debiandoc2html policy.sgml + debiandoc2text policy.sgml + lynx -dump upgrading-checklist.html > upgrading-checklist.text + gzip -9 policy.text + touch build + +clean: + $(checkdir) + -rm -f build + -rm -rf policy.html policy.text* policy.lout* + -rm -rf lout.li + -rm -rf upgrading-checklist.text + -rm -f `find . -name "*~"` + -rm -rf debian/tmp debian/files* core debian/substvars + -rm -rf version.ent + +binary-indep: checkroot build + $(checkdir) + -rm -rf debian/tmp + install -d debian/tmp + cd debian/tmp && install -d `cat ../dirs` + + # create a substvar to reference from debian/control so that + # we don't hardcode the policy compliance of the policy + # package. I guess some might question this but I take it as + # a given that the debian-policy pkg must always comply with + # itself... + echo "debian-policy:Version=$(DEB_VERSION)" > debian/substvars + + cp -a policy.html debian/tmp/usr/doc/debian-policy/ + cp policy.text.gz debian/tmp/usr/doc/debian-policy/ + cat policy.sgml | gzip -9 > debian/tmp/usr/doc/debian-policy/policy.sgml.gz + cp FSSTND-FAQ fsstnd* debian/tmp/usr/doc/debian-policy/fsstnd/ + cp virtual-package-names-list.text debian/tmp/usr/doc/debian-policy/ + cp upgrading-checklist.text debian/tmp/usr/doc/debian-policy/ + cp libc6-migration.text debian/tmp/usr/doc/debian-policy/ + gzip -9 debian/tmp/usr/doc/debian-policy/fsstnd/FSSTND-FAQ + cp debian/changelog debian/tmp/usr/doc/debian-policy/ + gzip -9 debian/tmp/usr/doc/debian-policy/{changelog,libc6-migration.text,virtual-package-names-list.text,upgrading-checklist.text} + cp debian-policy.desc debian/tmp/usr/share/doc-base/debian-policy + cp debian/copyright debian/tmp/usr/doc/debian-policy/ + mkdir debian/tmp/DEBIAN + cp debian/{postinst,prerm} debian/tmp/DEBIAN/ + chmod +x debian/tmp/DEBIAN/{postinst,prerm} + dpkg-gencontrol -isp + chown -R root.root debian/tmp + chmod -R go=rX debian/tmp + dpkg --build debian/tmp .. + debiandoc2ps -pa4 -1 -O policy.sgml | gzip -9v > ../policy.ps.gz + dpkg-distaddfile -fdebian/files policy.ps.gz byhand - + GZIP=-9v tar zcf ../policy.html.tar.gz policy.html + dpkg-distaddfile -fdebian/files policy.html.tar.gz byhand - + cp policy.text.gz .. + dpkg-distaddfile -fdebian/files policy.text.gz byhand - + cp virtual-package-names-list.text .. + dpkg-distaddfile -fdebian/files virtual-package-names-list.text byhand - + cp libc6-migration.text .. + dpkg-distaddfile -fdebian/files libc6-migration.text byhand - + +binary-arch: checkroot build + $(checkdir) +# There are no architecture-dependent files to be uploaded +# generated by this package. If there were any they would be +# made here. + +define checkdir + test -f debian/rules +endef + +# Below here is fairly generic really + +binary: binary-indep binary-arch + +checkroot: + $(checkdir) + test root = "`whoami`" + +.PHONY: binary binary-arch binary-indep clean checkroot diff --git a/fsstnd-1.2.ChangeLog b/fsstnd-1.2.ChangeLog new file mode 100644 index 0000000..c99496e --- /dev/null +++ b/fsstnd-1.2.ChangeLog @@ -0,0 +1,39 @@ +Here is a list of the major specification changes from FSSTND 1.1 to +FSSTND 1.2. Since this is a simplification, it's a good idea to check +out the standard document itself if one of these changes concerns you or +your software. + + * /bin: tcsh may be in /bin/tcsh or /usr/bin/tcsh. (It was + previously implied that /bin/tcsh was not compliant.) + + * /dev: the Linux device registrar is now H. Peter Anvin + , see the up-to-date device list at + ftp.yggdrasil.com in /pub/device-list. + + * /etc: subdirectories of /etc/X11 for each window manager are no + longer required. + + * /lib: /lib may contain miscellaneous shared libraries for binaries + required in /bin or /sbin. (As was the case before, but it's + spelled-out now.) + + * /lib: /lib/modules is included, but not fully specified. + + * /sbin: `ctrlaltdel' is optional. + + * /usr: clarify that /usr/X386 is X11R5 on i386, /usr/X11R6 is X11R6 + on any Linux system. + + * /usr/include: /usr/include/g++ is now required. + + * /var/adm is obsolete. lastlog is now in /var/log/lastlog. wtmp + is now in /var/log/utmp. utmp is now in /var/run/utmp. + Transitional symbolic links: /var/adm to /var/log, /var/log/utmp to + /var/run/utmp. + + * /var/catman: /usr/man/cat[1-9] is for preformatted (i.e., on a + CD-ROM) manual pages. /var/catman remains a writable cache of + formatted manual pages. + + * /var/named has been clarified, especially in relationship to + /etc/named.boot. diff --git a/fsstnd-1.2.dvi.gz b/fsstnd-1.2.dvi.gz new file mode 100644 index 0000000000000000000000000000000000000000..a461c6cbe00f09fda596b1f6d1a530b183beb877 GIT binary patch literal 40260 zcmV(*K;FL}iwFq5w|FlC17>q`bZ%rWWOiu)<-H4(W!G6ASS`PVx?S!NL%?Ikc1yCV z>|3|G`lVL8({!s^a<`>^xT_^KF*ZJR@42^*>fCc~pL1?km5>ud9%R5(bDLRXCd9N@ zBpKF3pfb=v!Z@rD9GnD<4exhn*G1_{`WcOR+X$PGi%0c$z65p zp0nTo{vY4}{r~N@iB~+ke`4axpPiU^#qUpi-^9eku8AG|?*;R}=O*6pr~4kAn7I3c z6BBPbIq~XNZ*g^Q|I^oZz55%Un)s)Gb^YNe8Q%KTV0AbdJQ&4czLpnZZ#Wq(6xpCv z46<-I*?!Xe@lqIvK^{K0>-mX$j_KDG(cJzY8%}oTng=$XyN&*8{-XZ+&E-uuzq=K1iB)J)zT%PUJ!Yxu%lOXkM{UJ%2azOc{C=^e}Tt}G~`q-*{n{YsaD zd}H_%|Lcvr|KWN&yf%E{&M=0rehHe0JE{3rX5OD{}^J8*$pP4b{HA zVO}5f`*GAVpQlM~e(%vhuvRubCbkH-C{=(gb zc_fH>@OhC!GdM4;sIz81$?bZ^F+N0Nl(wNMJKT1Zg{>mZqL7vfn^*m!PQkFhaLOAF zj4|1xc9HEfOanA*)&klY#?6YYCb8sh2 zc-+ZS^OxAXd0&u4=>R^<(?Qn4@f1q|%+yL0$L8}D^H7>C!}O=!5Y`Uc4)B>?3U4l! z;x(9B_$cCqG9ScC0Zi5+>?GLqz3P4(nDJ$B9L)Dx(7(HiEQo2I)YskexiexW_w#29 z>Wk^Tc?n1n=)WC#(C$SE%n>eSW5g?QdGoN9!qO(Rz{OI8C%YeHg_)!^{Lvi6JC|X~ zx}moWv@KV%hz|?CFzWT=5F2@G!JF8el6HtgH~->TVJmqX6u;TT^J^r@xgdi!;rJgo zYFb>LyYIfk8z0)Sls5l+-RAJJQQzQG6CWPx=iy+*Ns6Zl z<|+%?VK2y*oj6zu=qs?QX_A<;f)kJw>2t3l`TE8;EBX3S^SwvTpS`l#-1sPnbNpEv z@|y4^!IjwyR-n$CT^_)st{FK4U4OV}H#gvIXD-e>as_tg$hVydSK_cJW-gk=a;u#2 z^XK7E!chtFJkSVBAD$13$A-^$0yxJp{l9GmBpf!QpP^ST43Y~A&{^|?`TuiKE92b@ z8|*55dj2eYC8l34U7UB*eEz`&Sc4JG)w~n8>)E8mt@9p89)-8y8y6nEbZCnaoHBEJ z`K_1faWkjOkC`ovG7CB=uNytl@W{Los%ch41Gr8S+nG}^kIN~@7xQ$>h=>>NT+5>F z5?m~~?GrYZpmW4%!v4&9QJ&+GO>yYvUZ)ElMqALa#>VZ&ahi{aosdaV5SJB9Jfh73t`sG zLeW~oG6uNAs5i|Wj@76mAekm^*KduShb-!grnKgeM6(%h{{S&b?yUxC@b*GxO~ zL=uaLr7`7$#o?}h_PE*PqJtDmDV`^@2xhb`?qF&paKR_nEFPTKJ6C8SNIUMNtN_t9 zT6!83PdpybLKdPT@TK;k#dmH-Cnw2!Q9-AzM{`s;ws@xPX)}}3JGSxMYv}NN^MpP; zKRG;b9Q1y3iN0?0l-fQp4LFxDks0@p^jetEUe63|kQZ?2v`Oni9do&^NB7{PQ4xoB zGv#z)Hmo}0-iK4SF?{1J>OHL%-g*(tYU<=6ZW?YEkApoOG zz0cwUWvc64XpU{HkF9AZHG4V<%&{c}%Z%`p^n)jhwsGSqxB*F2y$gl{?4_t!i$^--S5X)T(%19OmLb6|4W!d1~s zH&0a>;^>2<3yQ{XDn%noV1u)awQCxoaueG&$k40EFuZx-r!_MoW4XaVQU8G>7v)Ar zcpBUe7qYGq4=l(hm$sWjH5%HjkzC7U;KOi^@NJhL+Zev-NqG24BPQM%8qF(+8#q0! zc+e)X9FX-}h$UprEx4E_o`qWk?*GM@G~UDrv0Wd7$%FHASExJ;W`1zG60ZO2wgvURt9zQa@ z@$~T7zl9#I;jLd?>koGwN{t59Uy6*rZFZc|_RZ(l%zq*LfLG{`=1)61-r zCamM(t{dda6+|aD33|S|Qs;`H13O=JcgR!x7IAQp`(w?TP@q&8wGsCMZhE;B$beWsQS>AU7e$Z^Nb6GHv`@BM#nLS;6Za3aEFDf0r+ZAbcq4D2emPDP@>kN9I-7n z`lLr;L>G8ZKIo(ab`04+aWAnsR%cMz!`98#$ywWrP=!L1=T6_GtlOC|#^arc=KI8Z zn#b+CPP})M*6UF-$iUq8i!t9#pt&Sndz9K%O5M?uGe$FCSw>^&gWuPg-Z;f?+hx7FnnUs$Kk`EYx_aJ*VkLH71d%8{Q5; zyH1Ub4fpyPax$3*@#zfohR9wR=6*JIe+1?sD=Oe&ZHodXBMH!O>=+|00b_{oIaaZh zKNBqbh>Qt1p-bZ6!k3xOnxR0a{mIa?j5|Uft)=QUEDHqsAfGT^NOiY#j3fzqWTjz; zL{~yz5?*4atKBFe-tpT@Fz5%?pzbwt{v@$)e*;hLJD9Qi0n1z z2@KvMLV1>mSWU=uMoX$>zS0rsrC>K1F>I9hHHxmZOD97u5gCE5le9J51lZxZcmZ|1 zE#rVV*dQv>L5_QpO~787Ik!)k;hCwMHBbfiZOW?Ucyp&y`9Nj?SI0STK?L5vaGIRE z)}u`Q!YRq8YbQmI-Y)te=>)wfj)F`FDb1{R!2TyEW{TGqo!dKV^VW;LS_vzzhCJ=aJJ?<7 z#kSn$w>}qC1tWH$o9AQe-jI8t7n&(BQ_{Bg5{#Oi@Zj4ZXASf}i0MX50+bQ{@Gp=F zZ(3?#+!@t9a6iSM3diPA2uH;3bn;n7?}+FH1>CY24eb;d9Rf)KDlXr`dh6rT?pamB zwJF1%s=IbXh;fW0BBg0%2^V8ze>uEeceB!YN^(*scx%wwwAmHzwgCpXKNwY}`cT*9Ki`A!r;iwg$%y_i-kj z(bA_z$CI#|`kFa!=A!KN=o__R`;?-2)Mva|n%I}iByJN}*VJ5EsPl!R?iL-i!A`KD zgyX~|LoMq{wjcaV*j`A9y;CvJPrx1#j8FYD%yM1R~nmab>iLUQj+? z%Qh|q+xS!r=5u$ccD?X-P#Ub<%)%vJ>3c%G`Hh7E9`ICdCXrh*$8sQX)y-J@g{*%` zvccYt6kG4FT0s&3p8qXX%0m;@uKeuj)-+-oyu>-pPRAUeDH&p-qG1%9@5?E)D zoDL)FazMD%i(*jR`XIr~hO)8VjBtz~$p(D|{y`68I}18^;OUxV->O{V6lRJj7zS#? z06u9OGfqusy_6B3r;_Hl+D^3?CD!P0gNo}%59`JXd%`NF{@sxh9xNYpjp``DTE5n0 zAEIPhDml)`_Hhn}Z30;hQG3uyM_~`TIXkGBxk#LxAncbF-esw2WXWYP2XI$7moUT{kG%2|+|@wwK#ksM3La%=dWQgb%Ih{9{RS9NZ%aYvdS3(O#27Q^D| zz;34`K#h7(RChCKHs+nN-4LjvNjw3UL;I8J_F2uY^3(_DI`+f6kNr{2x(;fpecc8Vq{-fyVd^f>0AM0rJZb)IY( zo)?$4F3)X3(-gzs>Y(Cn1kh--w?VucgDWR9^{N&B+F9|M-^)G6@dr>kvCn3#=W;2&B+ju8~ZqM_{s_m97Yz1;_T0ZtIfR7A>xFJn*3>K}G1 zz8GKtOzc90&X!*Fim1_3S*LQEDxPKb;8h_|zKb@3+t)N+_(!uBEVEY73Nr#O_xQ38 zoFBx^xkV(IL%BgQ;7UIu(vjns!^n3No*nH~FYv>ormJ4mIJ;W@rYh+_DMOJ7w`NUh zb4#=VTESh*DL{rQyagoE4vZ3rU9VZJtnTR4nhyb<6iA7He2AxSwBNrDK#Dj1;zED8>ma!oCfgTTucLs~v*~$Qt1_x3)yRt60Ju+Q}i>Wu5hrqm@8$G{)j(a7}|x`iyqr)ZI*|FQQJw za~|7xq*)abT}hZ%UFe=e&R9~c{i&Fak=N<0`O78+cTju}@(e#RBhQs6_T+%J#r6;a z792Q;7Zit8jeF3Hs0R|}RBj_6`5=Zo48h0wQ5-c5*nM(_*S{ELPQfm+)E}pXGRZ5@ zeSpSx{mZs+V3u5jXI)ecJC;HeU|IFnB1ZOf2bmZ?9Ax7QGb~!0=q5q=lRFuxJ@QsV zVehc@XVYGwzqX^vmYGn|ww12bVEIA)Bk^rCD9>|l`k)-<_G=@2Avmd1qkPXC4l$Pl zT7K*Statv))~R2P6+B7~F`t`@Ze|4~UB5c5_H>jV>rvpwjCls)p3fR(TBfk}ExZ8U ze40zyXh+6YE)C;cpv@5kWmHlw$Q3Oo4A#39BzUx}>TZ-QimB427qn*(-^x3_6%2Cn z5@0@y!)VDcc!RV4wndH*3#U3aFeHu?bPCeSPM7F`T_8xsF#@422+wO#mL@$5YNvFdlF|6>(tU5c!=No%6V^ABIbly;%?s!*(zhEuV1uxX|CcsOTV-BO!FIPR>_&I1 zb_pwi%TbAQ4kG17sBS^o2@sq!udusDnSgd*@GRqeyA4o-A=)BRGgXT7laY@AD>>h# zK>M_{?h?L9(^&3PbHi|WDlKh%3lDyb)EFBp7^yEftzfjjD})euTGeaFogQYWW+Z_{ z-Er)r9Pft%Rt0I;h@9Hk+TlYk%-n7&>wW30%gjjN0Pl9Kzv5p^ZJ)`cggTlK8gSwTHfZ^!{BE& zm6!~g3xfCLZCBuGlJ7uILhfnkfeYhnSXGSbIAyt`e7mMH0z7Q`!>6)7b0^?!syzI=R>CkaASumy=zL5YWkrQ&RwcmF{6vDy<+)Qx1C z2inV^oZh9uU-X;r}|V%^4aG1q9Cu49zK!*^~p6)a(4z4 z1*7{IoKk|0L!VuH5c+;iJTPoemrP+2J0xXr|B|~5gE|w}okKQR79wG1_`5 z=xyv%Ib#mYzlJg)Sye+ z?*YDf4mNxNeg49wbEh7bO}z!IfknTCHY9b<+XXxoiD)Ngc`znKfNDFecG!yeX3$B$a zIq~q6K(;OoM|*DF#e=EWox+hYRAc7O+XxCQI~j7*s<|$~FabrrgP4Wa0${wsoi?w5 zlSLjddt}O6jNlxP;Y)cyOJUr%*k-Ltn57d0dSYe2a%7d8;1IjLN$6|j{~{4DkK}_z zNE>BG`-o_y-lwzx)&peSvBTGYp23wA5vlaawxnW(l|w+drv*US!bMQoTdKV$<@cmWg|G&y0A5tvB=)oI7id^XAuMnT(R=UsJrTn*98AcK?Gke~sF zC4BYI`gTw@^3DQyu^hpxbsj+?J0aOxAnYzqcN1D5k&8JZu+y?N-v@ox9^@>O1z|yH z&YiRcjtO>>5zk~3iv-yUV$Gusa^<)vz%mu>OERdXccj)9J41)pbdP2whl*5+4?qvj!Av9$Lw!0OfO7mW{OwG-yN7|3-to;? zaCeKacILV}*~*)Pqy>@La#v1=ixCFP%YC5``YCL8kWuUq@ShZ$iO`FrK0evT7jbaL zYvSRv4`1NR3@<}U>kiC{NL!Bq15=iu{(cI=sOGz04zq5U(SQQ?*~tXXVAwPxirP(M zeLvAO?KhT8qnp=nJGS!F#J_j~t=L1(ihb42tk}Q$-D9v~VT&PtfqcR9^JV~N$;p^u z+H`rIFQC-H6@a62zma+^8uh~={&KR{YBhsabFf^V*h{$O&){)iK*#Am=Qvekn7VXk zL47hUP2&j6-U3jRw+pex0N0r`KwJ?3IRb;+-v#>za=p?R9V-y| zduXy)(ZGSVB}nznrhoW zG;{pe?4qJs1ZET8GpK9BDBAIi1RTp0OZBIf&P4})+~T->TeoZOu^bT$7vn*9#+>At zi-5SeYprHPr`iDsOq|6_k$4XaJQrqMf%)^vHF+hk*wbLOpdNqN=<)L|J9#+S#hVNg zts_WWKb;PD9VS4)txp$zzO{8QU`)@2hkK#9)K#7yeG0TRIc0~CA{wB-91}!hNqXFL zDKhwnKHsaEgpG;{q)guf;-IE?@vT6~qtYhkXH>GXS?!<<&rKJLxre-})X6158Fwh= zWnJ9b^lCVWI@*bN{uBe9gAO-XYxOpc`D{u+X&f^)dT0z8Exmpew(KohiGonxR!{`f z7Hr0EC^@Rd&PY2l>QRhe$hO7?savzV3Qh#ACTR(U8Y4&7*no6-?!sVFhkm6HL5Ld7 z1LSU9v(dFmR+{qDQyN{66+U4?-H=LLBr2!TQ69NON}~MW_t3b#Gcr02Urxy|NEMHpO7vzwAt*dsPK4m*EKrzoO7PuQ zuasz1R*4Nx0USL;3%|!*iHbaoJHy-h(?maD!ycTm+=>SpzOKAqD#5g7A?kdOFKz>u zlkc|QzB|}`g=Z#27`SZ(iP~eBRIQ929A-)^Ez3I`zC;5kR;{qd>isUCyt0K9?P2A$ zn5KA5R1D@o3<{qt&ob9AJcJxn7^uowgZ8_xPU473iXyzUtxDNf4F31QS|d*&pC;KP;!K``bUb=iceU)ZUaRNjVfheCYf<{8>1;nJK1<2zEUuH6ziV5T@YKhoQ)k#XO z)Lm3*W%weB%`Vp@QX>VIbCJ|18S-8y!~q7)Iokv-?A-0p{*qCrkgR0iW&o>PJ4i}? zB}7S^JSW@*hma%Ruv1=erO^%odo;#)e6I!MpbZt>F*A`Nj4D+mpBCEvqL7qCtLUIF zICBVvEVQqHbqT?Y@OCN*q9TpMEKp{4?LcUYVx$iLCg%QCbN3O|Sm5o_GKpPv!*20a zyD6EVYU|6eUygjR&ysF(BvI>|TbigQ3ZLXS(ma2qIj`VqF>}w!z;YZgpa^o0%de~ zy<4*48y45_#z)b+GJ4Nif(T_+K=!IxMsw;KbTa8c@b74M5E+5FqurMx%28(o8;+ub zjxKee9F+;8<%7JU*yi+@P2Ji?S^I`#6+ID$ohRbeJM%<5d}dr(6z2tRAjswV zn*+Bn-lilZHCW0iKlYe-D5g44*@!FCv*~2xC<2`=E-NH#u!5{-jsS6{N|eLQi5wFO zIQSr@sPIOq@N)Ljs5crMD;>BSJ6rPea02FPaiD|`QmR(Tqv{bkX-iX`RDL0)j>jrz z+XsRR$ivt8R8Ary1<6ifSe|K!vrd6JJwgzy4p=)cK+1ekvpJxF>5RfWkTV^^4KNE1 zD(~}8Zb{6@7B2HQq1lx<^}R*78UC$wB_T%|Ga9)eJl}O0S&ACSQ=kWq?T$z~bl60E z3_Wzqur!JHZQ4Ksd^EfxOEdZ&2iwi3Ad}A)g8N3QTtwY+RN@aFJ&<79ur8L(%8aC?&G?toSmfR%q{P(fee{4EJ* zRxao?LxNF)4n!>$noqs@(uYuL9&u9hH9M1<-~Q`kV{1A9Y)xJuHToO6}iTRYSgf zU6rgW426j#Q}(_eM0ajS&DUnFOG+97au!f)d}|^%n zn+W|CT736R4-T=|#R6$nRDhm~3fpSeC(HOa29M>+A-eN-V4j%nvu&6Tj{;VY^1|Ar z&A>Zdct9+4+#LQo^$Idk0AWQyEMM0Y#z^iP!A#8TAQAzut9E#e(E70rS1N8h;i2X^ z#`$I`NnA&uRUsJ#=kYYq;#$n?FEy1iT#%Lo3ZsO@_f{5QnioM>rBPR|&9))YhH)U) z^9X7D4oe*>dr0pRzawFsE4~D!8CQE^MaV{lGHX;%MAl@We9|jw)ju~)K1q**KZ1Eo zN~%5K4dmhh+7+Ojcd%C!j8Pyq^9;YYY*nUo=S`Btwzn_Yte31Y+pcJfN-f|dz~eE z`_3%U#oNb@BpUAwaq5KLJxCCM`Pfhj>GaGcvl}j)BVp}jajX4=dz(_X-HSX;TsF1D zlz2ndlM*x0W$dUhN~%X*Czvfv-)&da;V3}E{CWd+BO@f8)FXn9_EBIPy~;~Dob z*$4bgdyB&^-@-^=fpqtqUUse!Dp2CJudA`i#QJAXRM<#lRbEc5s|o^4=xi#Z$I)m= z*(_FJywu~D(mno|+Oe61)+VqiCUZJ050oM@FyaH-0CS zPyFM-jc@tny1kLEPy8?cN$JlU*I#(#`)*8r%lfDnm_vcj(>}iNpJ9mCCqDN+;9W3p z|G{5EFE<#P*C&21n027loxWM0n%T)&`gIm{E^^?{qF_5RBY(;UiEFs#>q)qh4`=tv zpPUW5ZI7<+`bVGj|G59nGxyCMp+DaGkKZ`@kGsC`o1_2u{PlNi@#Gu+*;B9llc(|K zJnC-FuiM$p+5i5r`EU<9AMT}exNFI%qkBJLi=T`{J6Zsj^KNDqwmgzcoYdudkXZR8 z{spO{kZfRwR|kPh%y(O`!AVmbZGmuvr6gpK!7Pf6EbIr7E5^o!WlEGV!{%|hW zc*ZaxNf%d@Tj4gk+Yu(QF!MB9FHaJXEuau1^pdb2P9gTw0PPg1Ah+_w06Z6oryDfs zmawByk2A;Un6<$anA9edbHCoo{W9VqD`tR65ih!C6@g6A5_ZOUE3sC)5*9A#rdJ}B zb~Mbji3Yz73?>y$b9;#@@;i&OFiKoE(cG-iw}kd8D{DkX;h?Kv50r!9-ukML0Po@r z&woE+dU&gH*3}NjUHDJ3qG~(JB-Dd`j$m5o*lSZ`Ww`X&BESr+hRl+Y>&@vpmd9;| zs1K@EF+Cn72J4WA(pi&199X?e=+Be^*6<-}9nnk(?h*%FInc!oEHi*~la!TeM;j7_ zqM<+vxm@Y!zz8YruIC=*YRMSa?*)!^447j5yh9Lk);C+{iK4Vdiu2X-yl@w4aG#aBSv^L(F*S+@0`2His`f^o9AwkmgNSR z?q)^q(y4Py@j+-uALxuV^^kqs@$*~H&|LG-p>r5|z&W049yq7BKLQArYuz~Y6HWYX zZWibdGoX9?p7^ImQB|ShE>J!fE)jLk5wM`l=AtB&>w&3+J*@{jVJ-jC%rY&(tg`%jRgD6k#A)vIg<#aRwC2_?oS?d^7rPUv@2aR&wc{g(U z{?p7^)^6AmmPUzV>i@q*`;MyaQ07FHZmmO&!R%K-`Wv)oLE9_!5}gtuxESb@y%&78(*rgW#XcR9xf46unRPg zuA(2FGeAT#Q5hJ}9^0;KEYmi^#c z)z&NdrbH!3i1<#6e4&~srGUCJ@Q&@@(l@YqBIIXYP)KK10Gb`h-*p5fsyjCAQeDx@ ztfp>9`$julak}_%NNa??He3~u?VW3O9u;0kW!hmqhT6YqLRPoChydBxdz5VuluUiU zwz<;k>f>MeU^f+K66<9t#2X?oa-vHCMks5?cG>g~vQ#a;V&nR)KYsqkpTA*!WNW9lZ7nr6Dm7;T9kQuA9=%FABmJefZLUdf z`n2Fq@T%YT&D+i)xG3q(=a_L!@t10uqqX)ij0n7;-0&l#fH-4lCXN~v!#D_SO>n1C83G#yEJb<7 zFr;gNwCC5!MJx@z{`7_Q2Lci5dMzy#O38N7w2^p!x5I)WtdZDRDk~0i+}J5jwf$nO z$lSbXZdT>qm0%Y|iCjI*vXMtVP^km2=8jvjn92H_L4~hU7oPSfL`<+-ar1f5bV3AU z@najEB^3WGTp5Jl?|7lc()0M;&4y6)ZHQY4^8zX{Z17M(L)Us(_+ry04bTTqzz50) zG=lMyeT!T$sbv-Rx~X7xfkB2Bk6%6!qx%}g=8GLPhV-0bHk?cDug`m~ri<{LbOR*& zz&IjKZUg;fZYvSp+(9gZ3?%cz$;D&C$$%urtxu!Gm~0{RbFw9B!enUa)F(SrAh;$M z0r4`qxH!D^$u;vlm{s&xK1~JPh19;3#!YWjh@gu3TBg7a25S^bsl-xZ|a!kv~K-0b6m>w zp?OQu4$)*0&QnTRT?)zGPP}v{9o_LVxR?yAOhx8VS?x(8pLS7`$(Q0rTl*8>0F;aK zxX|N~24xeS&GP})kfB}V9oS0&{RrR{D-_X$s!S#oNv<*8h{u|arOoAvRA^^o+tA=A)pPM(l~>$3dp4fC;|+hh@6m~gH=V@)Uft>~uFmcM z=^O8R!}=vT^?P=qZL<3oh_l_#!#tGYA6z(|v$EiHA45-*y%lZx3>^j~14i5_iW0i6 zpg{e(0lyUyDspvR8$xq4mykjE+X~p~lDOP)XAK2I&KKmn> zveJ<=JZmXCMaqXbp=^ZoWRNsNA7?EqEJu{77L1-U39#O4sLU{?VXwDyH7MD13WQ^bf(a#! z#CAaK#>ApZU`Jzj?l-z=LYjIQ$LzWEV2U*i-W5(3bwkh3;G2+)!%kO=RxOV@Euwte{WrH`#%0fx(a6oFe2<^`$I_HvM_YeYb+?{fdE(H z)TyD=AhF6fy{D+a5u3Vu|i;0U17b=Qw8E79Bmi9m$J;PucJbnxkga(kprpK z>PIOKC-+=AlK-(_mbMQBc5%pm>ljjhBF#9->y7$02i$0WyRjYcJk0 zi9@oUb3ZRs>LXY#6z)7to z&U-pEVIdh?MW52d5;D1`>#XK2Z}eIN52R4Nkisf{;;8BOiQYr}t;z|>CbEAQ!|hJg zJRa<+nmALEm*@3_67*uE(BukhOUk0w$26(Fs_GnYJ~4$Uq^wrf7ugT(WrE<@w)JC4 zqg)MJ159Ml!pY8kn&={ldXn6<#i_ZG%64Qs1)MBF#rEb7Hn#Vw86RMs%#VFUYwe9c zV99e2VqwwQ#o?|)Dg0LqCj)R!ax`(Wg%K5jAs6=mo{NfZz+$4pKTekqh)2)XVjcxVN9qC@MF zFkXf#THlM=)}2)GoN5m;ENYJL2e;iUItERLp1mw&Pzu!TGI`rLiX724i8l>-C=?Va z{fO5>pC>{wmTi&it_&0Lf#Gm ziKk_%Dw#sYa-`($hQksX~}zzIG$kY(46KUU_+0MYh#TRhb7@1&64bD&?UX zRsfBN>sSd&0#kNe&B!(_XJt|f=oF5E*oJE0$*W$mmAYt>w8d4HBr#mdYX~8))N(eH zn2-jI8i4JgcDZ7&Hm=|HU0;9WvCoj_WX^d`_Uz1a^7sDf*b1&4#DZ(H0PdS?frw+& z!ej?yr&@w3CCXB2lu(DuUD9!rjUV$` zR0hkj5?ezS7ZFakSv$~wd*@C)^uXx{9xX-ZDE?&uRMgvC)J)1?urzgEh^9m$ELnow zOcU=d)7WYW(j;gz$&BO{d0eWKcD_B^M{Jdx(Y*9_%2z~NQWuD#i7%tTn7mO}4y;r_ zl3?zv`37dhmvEXwP}#6zSMYM22cim`W5d^1o6sze^(Ims2CIu8r9-9%rKLMMV5Ls)ES74Gn=v@e9&d?K{waXEjb)=&|E2iT0c`RY$5y#QaqxbltaRs znEjSDqorjcrG0?jBQ79@Jyp|Xd1@So51YHVD&W9oAS8_UF|wOLXOVJPWOIUHzorRJ zR1>V1#SP>^sl%vJ?PV`4PJR+X2Gs{32W)?^I7_3Lfit~nu?tWt50oChI{}w>>(heE+jX>s5C*=KCqoaHN6-W= z_g;o3j8^hhFt_w@`kVf{QdSh%kt-7 z%<8`A2e?B=c;+0EL|#trv=@O7uqL3Ww_mCzjXG^w<`bQp6|e%bOQ9Q#Aq(W{QDZF! z1;nTXbJPn{m*UgJah$Cw<9Kv=R%cE#2&C>RtJT3}T8R9t6kQD`?4ElPOG@n=NIDJ} z@Rhka2DX*#4{bhOF+V*PC2f%f3p+$XZjVberl1dG&Cw4WhXuPL_4yQ>9i}V5qu@PP zI+ho16A?A9WnG1JWn(N_y{r>pR!7W*&Q~N3$3PT3KM+fa zs8DV~B|%#)^y1xBC=Ltlez3}^r<2x!MLJwvLHnS14Bad>3JZ}{gw1XfNpkI6%^K0& z>6jru!Kc&y0sFr>E!sJJZgvHnok*v%XgjTLriqFA3K~yNxzW2=ucp$%yebtrXXKU5 zdUp|Nor7j8OA$NgaX8iUd5B-_`4CY@k+wYA#rIZE}C#bUFa zoXcd2iwmsKfxdHvjfTWn*aVC75@M$Pg7RGL7@SyGBu;M)S8Ue4oAO!l&8}1hyEfA# z)E1+j^ysPsE*S5i&(i*Z>eB687qqGOM#+xTmC;$K0G8CV;n8o*?7nBj_)KK#e(H)KHLy!HGUPoW?r-6m3LL} zU5$_~VZj{2P{k*udI}iavE|+~w%7m);}#l>VT(@rCEseePONUoC_@VQ!q%~tb zcL+v;X#)UpiS+(L?@SyROU7vCk}9^u^435))0dGzIwa>UM?`#1SmC6gIwG{)>H;th zv(|o`Ox?ZxR=(5}ELjHNpCVX<&pYitqQjC-PM;*Gb{bg&0J01(RrnOtQuuk|&mpq_ zD5v42NCy}aFfAik20UTLYepok6;Pa`6+mbE=Bve8KQ!O@fSK-(=UYXiwwm{vE78^2 z+wm%dtHvTIa-8j=&*? zsZb%A6Ywn?79`%&2+MIVE7uIN;PeYuAHoUqR?OwQd%_-!{35?23DG5@C&YB|*5-Le z+e0TnJ7wRYd9-hHJ5DcF2T6s(Vi;6w%LgUXF;l$bo>Cssr6qaQX3|N~>#tZ?QAJ55 zgQc!+IQ!>i8`50sSc_PJ$_`Q-3Dsmw+UFM%MKhpiHeHq$3=aq}65l4`BeT}G>L1rg z>8K#HWsRxPCs`Gc&BOi@=I}%@0Dqdzjo!S3JNX)YU|w)7Flr%wwnm?&{Seb?V3V%_ zY~PJdh#{P}eoAUOFleyHCbCE$>Cs3Ad5ln+Ez-qn#*NZvo+idvp^No4yqQuerBLYn z3nr!u$pzsdJC{VRGY*+7F_fJC)P_xSR``kd8a$mz>dNa{6O6t2 zyh&aDpgJj4N|O>PspVKn2NDIa2V<$6EK9|O?5nKCV($?07#pRozhY)@>fkiUcFJR3 zQ)HPSBLW}j0>hA8CTo_H!Upf~0!KWpegYqD7%y4HF=2#8DGV9s#)g5z(D^`v^Jf<* zLjBaPw|<@sri0F4n%tSe^s#V^A?hP=hnY!aH+v~XkWcPp+op>TCzmi;FjyYm`c;Y; zPquqd?z%mosJ78i8R87@1&d`gK1UoNRzkStM4&*9g~&94ov$sGk_8C>J3 zhCS3YFTX(DDNX2z86kc~+`K!R6bsSymC5xJ{q zt8iX5E2fHK82|`7=%BzKbcU!F)`1g1LnpJUP_V_hp zO_-)UvX;*{pDz+{CvcB(@A zh)X2tE;Nc2cDVB%6C?tdmd$D9R#RyYY*?^+5@&=3AiYn@jGDb-_LmJ7-wU@`&scJMv3i6MY8KKkXb;s)nvEF--p{SaGY)wX6sUJ!ZK;;wgfKs^LX0?Z!%XODGIJd8v&lWnbVPIj+F8O8u6 z!#$NEiA0o#T;(;zP)V7^<6)PtKJQOykDAk;O<(ghDl)v>*L*s1&$~1PpZ?iXy#+5e zYZ`#iMB&p`=TR?0Kw8hXk2xx`W6XIm*D6{dwtObTtreJB@GL1+*R*MHg}Fh&rR|7% z`=g10>d*qxO|57#H>OefITgZ-6!6O52P=;YZ_({%$V=q*+hmsn5pDteTE#=ODMv}= zcq@HksmeA~ON#CcL=4sG@`mE!HMh?fW;2abA4rKri78h3e4UXaS)g3++_aFCTd+Q; zx_)8hgPP&^W;z4#z&TF1tJDSa%k-JJF_ft5+shAna$ymrHUgDgRYJ%9se;0@RH2q8 zhXE{nwWBGY5$G5zvv=IIj~bCKS1k79)@d-JbCo!UDsgp}cjqc*MN)s0+!H)`~@;v4>_atbvrX!|MiE*S$O-HoYs-|iq94_;xur~4{}V6P~;*c zObA}G3%F(u2aLm&oWeWgm32ZdwYLYQCZ{ol+c>u1j*L?X$dTfBv{|^3>f2!U;5yIe zjvZ6yfThD(59dwqH_`1=)a6f&p0WB}P0?|b*%i(vOaFtD=aHe=Y$iH@g`}mVjs__s zoTdZ(T81SzbEy)M zvoA|Nj&hcY)Yc5km%b|7D6T%v(5bau!HhcPrw&n88rHdz^iL1-18JVjYBr)c6CtFW zBbxR_W;uG8PB^d4M;w`gZh?*umy!fVtToAj8l300E$PK07qBscxZ);LAz5*Rpi!Do zUgEUG9Glw=G$S1oyo~}EXyHphm*yj1LnO4^iDdLDrvkPLcRJS`zX}Oon2BMj+yrJ$ zt_~S9`!R(6s@4w5g)5heBUrKERi;pwCTDYV>{aFM`a}?Fvh0DF(iu!T@>fZ7Txf2Arpkr>>Z-K3iYXEL%)A;C zCHSrbUY2apIFdN9??n>LKPaq|h@)3kAaKdBtx`}+K*f1XROo-iVM`PRQ{UYFqfK2G z3CG@e%`=jbi>lf*UD`rs#+WqCPv??c*3$l_bQ%Vo;0u<5K9%vY3Lyl5qqZ}b!=j77 ziY4v*hALQAuF{}0tIPgKys-I*koz5Tx^$ggR}a&=_e2hGy}8g8JXRAYQXverW$TWc z3cNr}Ytdzk_!aC#uDJvft!vkmq^M?Q+r&Dv{}a|ea_dOpd}_}xtr^>${!p&^Oo{{4 z)0LITY(emZMA}lQk`27M4B8m-BaV!&MZNa0E*)O37Sz9cCN`FL!6;;*G6JgqtwCS; z&gj!_0tAT>LoFjxmn{}c;8#e%)n{I@w6~nEAigJse?jNvpE@0cK!un|zz`^vkiP(& zu!Ev))r9&kbc|vNxuF0cf}fX+@I#~${oBhz{%e{q!Q0HM5IY3VPhIdpxRAT@!dXW>*MndXq zUdYJEM7yk1c+UAhju~U~{BJxp@zei_tj)vD+T6P{YxA=YjRR9E1ZXh5i$Qx4_A)}x z+Jjy{Jb;sW75>EuH`C0YnV+D3%-azoYknUTg9QFm-NN@1r{aucviC}f=l&7{BoVn3 zcFs$o9}ke`&zSrKbcfDoDcm@~efQIVYBI09z>6^4{ld0~-x9!!h_vWK`U`CN7&d!v z>Sk_!n0C%)`Fjs|`7jQ5GshpNZD|mT_pl1SR)tr~*9OnL0YHJp7$SOtE0TUXsI zacOxHIKXLZ+iZl~Io78z28Fjs9eJ|VYE3r^8^RHfEjf6CRw4dPti3W|g99DD*8h#8 zv9=#Lk5mwtqnB_+xpkIx^r1SD_ymb~tQTh8Flm8KnMcJSkis~h1)q*L2bj#t#)|Kg zqOHRqBnTNs2x3i`Dkx%oqNB}L_IbPg$a)KQ+Gz{EztLlB)9az4e5irAa;-YJiDRVN zy#mnl@`GRl;g-rnWsqT@R<%_^h0n0h^sgsneX+q7hKc=%`NyBWN?uL(s8+ z5=?)J@PP&Cd?X#2q)0ZQ5nLxe2I6mOZhH8Qzk2o_NfhCPdcgRIfz!6=hvNYAJ^{8n zs0s)0NlIJB%4Zt-Saok<)*p#OnYWQ@!o8^8!tyP+88ez zy!gDk^jws;%-jVDY-o3zrIsj$_7BDxm`BvM+ab{^IcT(rajn+CMVlG{#N_B9UKoyS zOF0Ix<^kH}8If?~Ac^0Qk*hvuGS=G|#UuSY8T#SQ%Qej<6g)2V!g_J53U>Y=f z<)ebk#H>tH2f=`%*XJS#mxo`89Qb36BkUY< zHDA+8jPvss)#4`&i_GPUuC}UThm!IwIm1+7W5yuV0(!AWUN3gIurf}2+Q+_4ifrb< z7-Rm5xhR?D(x;+(Ug^(LJV6i5&pIygpLDR0F}|;yyGifVs4mE&gEtd@F1JzHWuR3g zl<+mM0H#Xbi_JD6r(P`inv`z{``x-eIMpsAQsJEK07f)ZpqNH5Virb_*CDpGYw%zuNk+_YNE`YQIMw8Oj{pXnnm3xVJ2A8?#~0=C61Dc?TvtC1iKDOWz%7X;Ixp4Db0umeyc)oibIG-E<18~$5lN+q^J64#vwE+ z`4l!;sS+R9QeTFfUau;J2$R$np75dN6}-MIz&ns#f*dlrxWkMA)3D2~Y6`LnkWh(0 zBqx)ivD*+@3bm(giu4*`YIA(Bm8s?O7=FH!+CEjXO{A9#1BZ*Wekh8p+G&#<;!#J} z3N=?=nJN|4HLt26))omWzYGN=1L9xx*hlETxYykmU%#{a;!jt`a9{k?QxpH-jq8V+ z!?%10Tnc+X0SC_fbB0S$-TKJV@Ydg7_)%IRuyh= z857G-X3i=xPH@;?mtxj%=E_dkrrt8Ai4YXVPsK5I99NiCvs#N4bnqNdg9`H2q+ZUv zkG9hHR6WB4PM_qkC_-<(C;S@@f|3}ZRKz>3vazbuR73rEdHCo5=Z&w69=P#ef8dH8 z-#gDgV*d1i>6#xqb`$|5TQI2Sa|M8PXBUL{ZO#%fu%Xxr>I+6xUZvO#6%c!>60xK| ztT`}`y+eF-GbTBO6yZx<#ntH&maad@2$X?9@>7XrNma@2ObNCPSG`2IBJ!vm zauxfu4^%5{>*A(ms1iB!Gq5{ap(JbYu7_ley7F-fOzR`4r#QqGB%}pRkBfrm(h*M7 zsGp36=ct0p^K*3BQt6`f$QY=2t{go2(mHWiz1f56^Ng+H^vH+8~~F7njwcltfr$%DbYnTuYliU7&6>TGGY|^ zXUzvTkPME|z6&k5y1nBp$@=ilE3t0>R=5sqs+fhpmda>?0ED_1Qj?hj9c1Xl8f8B{ zj_R<1ocRk$Ou6NRCmtBfZM-E>&!@=@!*b%$$hZ**sq$$laD;BsOrIDcMcv9(qb%ZsectwlU=Rd5o1YAinptmtJ1(R7a{!tEpzwTJpc{=6*-(isf@LW*W_Cq^?$U5~ zniXEL9#Lm?8&+eM*#`<}iN=9RMMwt~3A`3jJV~(IlBNCAkCIV()ET9Jd1prHpZ)0A zoS28GkSh!bRm|aJ1fI+*=0DQzZhdNHIQf3j?k2-W!N*D3-DGIAyUE2%tldp^k9a9< z)tiCA=W;gNJ7SRBR*}v0$)OTe;(}XPAuR2P14p=3YCYK=y%(Co2qJ@DiLUuYNqF|J zuMxanLSKsPjyZiGOX3M}@_680!88+Jr(jGcTM$fCT7we~y85d<-rmty7u6N)Qth^R z(()x|0mS>+hKaS~9&a!gON@F*8E#9HVOJ`FXV)w22+^fRmV<>@$xW|RUXQ8+=dyb$ zE+Ky*w<{8a_OtThYp)BEW#gx z)uTr?ZoK^ufNhx_4Li7@bih}0YP$3`cclP7g{?N=V9!( z_62QY>p4hp(p)TbC8kp~jDS*u_RhB)hXjHX7AM6~f(-p*Y%sg(iC$yVSZp^Du)Prm;NiUEep&V7l+B`v_Zv z-aMhR?x>4-Bivfl5Au81x4nqMSa=ssr)y?#fg(5}}UAEPaFNaQGZdWVx85TuU{ zzp@0L-pNJs^!_wR&`XNxe9tR9vjMj|6Vkkx z@BD2Q$inX|QeW&>TvnBG<6Cu8;{0)tbO%HhRy`6@oYv0==e2Q=OfR8KUIqv2m+=aj%c<<481i>$2N!ns&>N; z-uW{X7g5Gx4u=zr5?B9=)D8h!`+ep2JDpAR%r#p!*eeLiF%Ci_i^L{}rkq5Ilwzs@ z%mLvmbE{Dv7Dvs7S4X_a*x zyNaWqQ?s#zCKYuK~7s7%XYHkobADA8M0T_gtL4w)nV79UMs*f^+ygML)w`5s7$qcJt9xQaI zScV7M5~X#juu$qMk&tWe(%*G4b0;tYxncEYjTBtmrUZa=L1Q^ybA(UE){6R?&Au)W zVA&rmqb(y~t(30vg?gxP1|-+hK9>y@&J?epN&M7Ym0ZfHG-ijiB4(HrG!0YjS7eEI zfVCc=5iL}{0abCU6k1kU+5NVNhkde9Q?J$~LL;7R*(N&FA6xFWu4>^Q=xHQ2IOQ;U zTTZPe3$Po`#i5z^r`A%mh-$<=jx6OON%^SKkIoUA)>FYyxvf&(`4oK7h;;O^ID$D& zKg7!2cFv|90^WYHw3|HLf*or7TPZ!sb0kQzmLzRh9ux1*u3v;whL_So-0;vv!1Q`` zkT8)ibja}%SxRiTC~L^&FZqRW6t$L7+|0pc!Wpb=Y|S$ffx<+v6MAkJ%JU2Kp%;$H zlnR$gS1`kXt6J1iiX)FuV414u(#T*Zb<0Nt5m|AWP=1r>AK4Q_(9lFvBiN)lG??J9 z=Uk#=ivmYfZ^7GJwsKKGBqsWb^Qd;@?mr@Tzf=<gjd^%XQBQ_7r95<`9bmAo-DJ0OB zx4CgDu2BO+@OSta2Hbu7+dae)osID~lMK9OUTg#N+as9Fs=Tb65RjRdO)4s+vgKXv5*U?rzcUApuzcvh}74;-HMw1^kkfzvza zK;%Y$dH&+;*^8?B>&w$%Usn0;XD?m>rR}_p7~++0KAl~-cxBo;roM`fY&-R~^bhyt z;s}WZnjMrfLc{Uw`3Ek~AQEYM408b{Dfr`M_R(KJhfDtC7`MmKUf-g;kWK4c)XGxF z2z=?{JXS6r<0P9F^J_b3l#48ZZZgizW}30`ghP>}Z7^`JPJ|KE?Iy+n`T^xxmSOb1 zlh(h>mIQL@Z6U42csHVY7@bpe1XUG!FGMXRDe$Z125wSmWb`5?MHrg~pbR3mKrFwlrNT8g;%>GL;myASHp|Do&Gq zQ!m1(n_ALaq$6h4AcVG8ezD6w2`P`e9iL_INU3S0~Y;2r{Tk@xCa>xN>d+BM$A?X6}UeI9GRf9yF4gcAHWraP8Wx} zKK3{z$XK$8hU4qVXmc>DiQsY7PG@479%pgln7s&yQOhu!{>f52q7(?n*fd;Ol{CJ0 z&d=Y&Om4Vm2^FHazPy^>WP}gQe#mq-j?nsVPAl>{2}`ImEMa;~<06aZwjcToSu}Ib zqWQ+1Sv31TK3iPTH;9r2yS`aw!^X%F4=f{z!09}^l#h+h#SBd}KX6>A=DXK1C;RON%U@Q%<_T-T0 ztkKzX4}uX$TjSy9c0cqd?_Zmk_=aaECf;;%;#I9)Hn;z0hX3^k%vVosnrGzE;a7ee zo}PAW3-QhqfwrCb!JyS21*v-Ek@<^bn2#rn&8-&Va?}f-z!ZXhsk8!4Of^-_Xzphs zh+nZk`uT37TykhBP)eJM<8oYR6zZ*<=%0s4yGI=8x#jQg1Q9(2Xu+rWp(s+e=Me!K_bI0u}@H{%l&1T$*^1!D@71+LpI+ zTfkv3M-m-tYeKKPPuf#RAE<-iZa0IG1$9t}EHksj9IAI0uIw4`f&t># z2h5op5SC4`2I`&UuSJk+KRE`T7Wm89)1%EJO-Gz?sCnrAh0}npDl;BZJt@DmSUY5i z=Ew8|PBC)QD3uAzS|Etj(c36_DH}ThQ5|zCwwSrqnoeX4l*km+!7l;fGKUz$D!3j$ zkw-{Z7i1<-akPiZYB@T3L^~*AJ9=xiR9!toLc>xdsN@L6f`H{rZQRk1IF{;3m0c5+ zQc&d{b#!SD#jk+V{Z7gW7(rQNZB5Yif##taDjP8J*Rz{F{tcN?W*rm$Dt%MZ&{{ad ziF~0;@Hn$EE$>k`cRYc3h_E1AL(_tcip^u9BGyKH{TGo6r^GVv38>msPyj40oSw;% z^%{qQ)6x)@O^HMFyxa)=mh(W^WK(vBm2IrwNb)CvC_*R!oR}E9r85#wI~^o!<;1BUJj~?OgBy!N0gQa zw~@zh?E_3?h0LyX$P8~WHmBLwGx1OV5&3!!IA70S*_p3r_QPXDP9L?dzjV0kz7|&a zMgJd`p~GJ#+ve84T^io{*BzaWYq~-2FPaR^3S3#XO^ibarI-oDu3k;5KtR7L>miY$z@SN9E03Y zHRP2p$yG7DyHHg~XO<>cBpnHwvlOX9(SN8gBMszjEiC@1ip1R1xjuH;(91WH8DebN zvpxld06E9Vyx^Ev)M#FA5|(*iNOZh1b1#07FN%=mVRr!h^v)gn0KXbWl9IQP*hOBl zzg0O6)Y_55#;BOxu}qy~9XW?Ew?1jCRjKtd3@{&k0!G!48Yd@+n$(=>L6RyxNTs5! zGPY6bVbYMc9;%EnoTTPSZn>vG{XCy)>abkcH>ASdAZC8{vRc6xdFu0<3&%vxzE|D% zVz9`z%gA#wI(53Du9kV%M0i$jsHStrrInvnYw! z#IIvIgeIMLHIYaIhdt>uR&eIgzB-3MeE)T|r3sINA`@jNW{=~9geTx7@0pvq@4cY+ z|1t9gnyE}&j-h_ebHmCztP`>u*>V8vf`o-*U8d5sdF)A0X-?J5$0+sYrQ9hJrF?{V z>vqmWc6tXdKTwW@ffyUpyAOJIJ6?POPEqBv7oi{wsF&lpfe%TL28mwBG!lW|ffYn& zp%)ZmdiN2{em9;uxVMfla6G*|THY^XS1L>+_u2R;GyD692}Wi30aClQN_1q*U;r1Z z76uidIp&Jk>lZ~7@{7xF<{97LsE@uMeNtW}2@iQ@n7U%H!AHE?W_5vR2w_NdP zG)1|1X1Vleoowd24fyfD>+5f%Ur#=PgU%=LO*``mociu@l~VSIS-ng}33zcOIF%w- zrflaDo|50V=E%jYLtJutEZ_G_%-exD3^Zn=ZUvMx zjXKQwjw|Nivjj}J`p|I^^<%8>WV04@hHro5h?vF9##YjD5$c-y^{mJ^LIF7;s0CF< z1|0!n6(H=g*>q5j1Ub|dY*HlzPg!LEF@bQ6^_L*9MR-|FnE<*L^A?n{k{$0L#z_2_ z3skKkr%OlWR3o&eTC%#jqE!~bQ&g$ih>cZ%-uM|R7cVTF1?b$|{{07=b6(jeKTu&* z*p|^s!8z*mD^V3g%_g(Q26;e_#i2ZD+v_2JE!E~m?44sNPJ3YiRQ1mykR%nRJ86}p za*%pDz|x5^ws$Sc(xgYkG7J#}r<>M~Y&RmT>~?+`bjRZ|vnSs39mma@WPn6kJMrH4 zG>^Aroo3A1m`@tVuMsr$#Ctb3q28MdmAbcpe!C~6>at6LS6!C3GKy7ltx<~jk%RXk z0s`HrvK_QL+*muDY|R9XvUUlv%qC0vR5s8gVc z;w$r&b4fd#ValI`gEQTz$>aw%#VMv&)-|*^V;fMo5ms>Uc-KbvzEbm?$)uzol1OU5 z%rYNizDAC>GpI41H-F~FbH&`|jXfWN$o|W)wgVCmrG=%5t6N(CbU?vpyS$dt#Vtc! zRGtsDu18yvjvy0ZCsWx6CWRT@GRizIIR@JUZ}%RavcyQ%<8N*hG6!{9XP1(E5i@$tFv_4ALHQ89j1caG)^lIZH7M9m`jIHgCq zazmJiTc^spWb|HCsGhUB!13C_qUa13Sx-|q`o+GF2P3)G$)@o0E{9tUl;f}-ERCsl zIG?`S9uHh7(LM?pHw*J;hZFzmEFd;qp1pLv?j=(eY{rf#qb(@~bJ}K66JKCbc7T~d zPF*HmM@6_-IQ}PCA?19u+OQ8SY6zJDDBsO#+!6EYzP9VC=FGzi2I5mKtCUI-Z>50O zZ;UOk9oX6wNQ_kNFsQD}3>Gy)Jo2eV371(Bz^cf3%bx_Pdl(|EnUM}yNpcgAAD|(_ zAx1JEdv4ioeAH}2n*zd{(Wt`c_Ll=SI|%p86D_u4G^jT@8S zQjT|io%#3Bz5DNFSICWT`Q*CLMLpbk^7_Po{wCU=&z`+`ec~7ImQ6GpCUofBmmf(; z+Qtu=0kw_7JUcn+(eHTY{Ue`-JODFoS3WfI;YSweVPe`%Xlp(Cn)x6J+QIdSr)M>l zlX?2P@32pIvhSEbWoGbS{ZA7UyCx)tR=(22jeWWI#oeE&P|zsG#lNQ>RSOi#fY?fzx34$Sxe4IIhczw-V^9x~th z6(p_uWi&Z=|Lc&jh5Np1-RaigQ##RtbAUdjL(Zr4%{%icz5B!C@+p<}ApQy>^ZLX; z+1PR$K6r^X@jJ0D&+zoC`G*(oHmCT*cd)5>=*Z0J2W}3Fd+ej_@H8{iJqE5}C4DVQ@RE;fs-%K7P5l#?MQydopOAXx5rHDIjHi#mb z_y6^3(3*y(x%*nE!10i{DWu=MY5qcb;j|Yzp!5q07tl1-%uT2@7h$et;Ol_vlmT3z z1{$n=o7K>z8TFH-d5!S7lWScQU#%(A*@oAhqdktof%6n4S-M+eK&pOYHFsNPnBnHC zE^5tQMkRa+3u}nC*4d6*oE>B5qAw7+>+owMkMItAf|eCb{OTrg-j#b}t1&{udMc#I zoOt8F*e3JPOF>p9T>Xx(@O*9W_~xSaw7ty3G3`3lU%|v|eTbtfyt{g~;MnRM0wn=) zO{R2>pG>=LE1s}Qk0C)a^Q(iaVwmnjVIQ;baLO-Y^Hl^Pn^LE&`@XNerC}hWbWJ$X zeQe_=hX;;>r~Gv{hp*d&82;ulGx6mJKGb?QZPs08f@kr3`2E3R9JPo?tp#oX@=IOS zcU~4c>MtX1nB>}d!N`;|CSFD}E?!%kbx{LoR1PUFu7Czr9P0{8*69%CYJ`3VSo#rP z14x@cJE}~2Vlas2&(TGgy&mbxyx!!zQ z0NO6Tz|aE67r}=q#2Bgga9-sZ_X&3z-k~rjp+69E1V!B;XP+nr%ad>fCxPHKzIgHW zzdwvzr}?x)V+S{EogrNZ#Hd5pB9h!fi9US&XHWaY{}K@+m0ha~-q6j7=0b8*BL|1N zB+3X_-58*t<}A}SBzzqBQM7~65I^h;@i*+u5O4j#7z}Z^@vsvz?f2re`w*n1x4Jt33CSpxu0<1cHF&=_og7lRDcc^<{Pf^?FWkwH!8fsXr8SM zQu%$>5f{+pb6tP09rf?E5QckTa+^R_l#oX` z8F_+nXl5rbVA^}n1B2-F5^bB{TUtSGs~03x(_T4c%bB0$xw{YN?yJLn`Da@fIl#HC zC4;5-k~jRSY(^lr4{C32JPlw5#N5v9AHMP9HY1i%w@?<8PVBAE;EA1VDOOZVlWr3? zG$wa60hNshCie9&+`|Gv@d)v-!_^klAi$b>@tP`+wN-KyX@w(puToyiM^@R8rM;Mi z{UFL3x<&BtOX0*!ZdFCO?qVfamBlN)P?CdM>Do3Kl+&2|5tT=03#@d(SCXFnHK@6e z+kv?t622iuuTW(!@fIgmH+w|YGSWQ4i&{{m0%7F|6-m6y<9{Gjn0K*K>h7^C4n zvZC$R{s8{7Hq6Tu*rkk;j*{lvz;{uhwlIGn>bN#K(8!uIA9f-r^eG>L0trH>HN$|a z)b#+3{je=N5}xlH{l(btkO!(ek@Z{Di+;Hm@Ry{Mw}tp0euo`odSwl3DuhupVODbS zN#T6FkeS?c*$#UW9%Yg+oLi4{jUq`Ia2Li*rw-!k0LGKzDZ%m)7Xn*P_@-%B47BF? zgZ#X=;e^uLKCet0;*-U{lzHK(ivTvjo=_(eE~I7JfgN-TwhQ)Aa>jkO>M~fCh&JTT zB_jjqsVi!=*oJsfO<{EtDlNtv)Kg-oEpY)p=Bh9H4&kXD-*vY|}#txuQBH1B!`m1(~9sbV7;h|}zqo98^@qFu+2d&z6~ckjslC&|$~|Rw zEcGtxg$+&tPZ+B)$nr2ov7iZ81W`*6)#ZS)N{qI|m#Aiabw1CU5>0qmaR+%t6&C}v z2HRo4m}D;Jm>}-fmPNDr>k+FGG75!qbT}0)Zw+!H{nQ>kno_qR57-T9HsNF!3$~Cl zGuduI5_TJ6_22sK>+&Vx<*StW9!H+8N8ns)zydhyTr?Kde@b7lpmKhxKJ9SJWIOE; zD>G{l?GafG>jT?(V$W>BVT_L*JOX{yyer}(0Bb%dlegf90GQSvFfIplm> zXRKnAx86!$~lcGTjKBsuSGlJDduJvvwged7zl zEas9x$V7DYT(q?^&s6z9<%){7zX?)uJ(st^cALu&XhBd-=g!Kt>v8%zTqhKnP`#oZ z6|U9k4>f@^eI)Io(4Fh08K<<3%h^86?v^_?iP6phm+EU?6lJ9Y=+j5Dq3%@#g&P#I zA!UEq?m{@nN(fDuwiCv&pzNrwk+NABGNH+mxxn-1{%j2!Y8*mWH?f{u*DW*8X(Qo2IqzBB!1AtAJbMdLjUbsie|BM-7kUx3`EeCH zK_xG{Cbb_HY}}yj=(Gfj-^v24r;7T~Qjm0KfWgOZun;75k8H|@!6c|T3#E$Dc!4#ELl>2?7o4ph)0KG^OG!X%d*h~mHnM?6wmdz5SRFiPD^Nhe0X%X`)*xfm@omjgwQb^u@&Q;J znN9dWW>LP^Hl@5S{oYyzH?t+Tgb&TmMdX_liS_$iV$gyM)pXbVxMp8~J9L%_JfE=K z6Y6h3dc7%X6%ReibwwN8n__99Gli2>3c|cCb0NH_s20{ul}BA?mb)USWavJ?PIxK* z$j+VAOc}2FimhE~K>(>=4AoVkv{Wvfw=>8}h^|stY6?SlX`h)X?Xl46x8i-&w`WZ_ zYr4J?uiaT(<*$P`t{f|@WM54JCk|W4qC%z^Fs38UfYTg+Tw%D6{+qy?d8x~yTce1s zLak(!+0K|!Zo{4-m%OcP1$dABDlFiX4tN1eHE8RQX4FPz?3lTK+JlxWxSU5%Sg6_7 zJ>k?5GBEmtOE706cZscDv_G?{`mT@DrjuuEq8e2jZRlwkL5$;9uv8%-$pLdL0^*F8 zdcM4LbXWVud(|OFVj^~|xw^bG^*F!?+ea5N#i7mN!Tms-tTx-+2M2=9kdCM$;&gb-?#(dGPLpwp|H1E%^x&8fz`rgKq5LRe00b zGBsYh-wLV<3_~T!bXsv&d3Ah(ZW+H+M|@ibm^1P1>~YYePi*?MvLaAqvLMrcghe>w zbZQ!1B337Mf|yP0ndsorBan;t@Pl5&9VR1GE(XHjB*g73Wvof^p)dit)fT$r4xLtd zr~NkQo*ZLT!3+XR+EaEwoiZ{?*&8lQq@Gbai9jfiHp?8vDS?iTK4Uh7K@uF>w#lDp=pbJu*!&fGPBXJK4 zpkTtl$v`rZY2FQVa zy9Fl;Jzy&Qh%tj96li&K_`1!DSx5uhLFTS>+Oa$EP`PXa%k$>OPuka?avKyye07(O znAV0WiGzp}tlI$mO>_ME5B6uN2vJ*uBGTE^OJLoHXQmN0n%<@iq z?u%xgo#w{ylOJcoV}u1%7>E3==W!2b;cF56o48_RyxIYLOzW?xgc!qb^HnO@Lt^T& z1Qm-y(W2M9(xcgNSX5-0kBC593V#ohZ4zIk3OvHZ2^*ilw;|lCVRE z%509mB_SVP7rc{otDd{tUT)pg;dI@MQ!58f%-UmXTKFEUSpw!H{}n(hQO+69)Gg2; zep^^S_#^WzRzB5plz;rJIj^>i24m_Lb8Av71)G>gYS^fJ3)Ai{ScOVXl`XQtlQ%aT z=S^T1|A6pm+u70yJYdko6rI-gCXY(L9qrP8cW4X`#xP8=o z>OJa+BNfM%vO8;fDgyU!Sb@*H?l9v6+Gkd1NNp3;r4ns-&}KN{y^*K25An};p!S0% zgSm=B@`sq~$;5H=WT0@*h86i@up5rTIZ$}tVv8HDvxktzm(-%QcXxe(d z1WXcC^<65!3$Shzt**e3!*&#aT7Z$V(=(TbFWi0MT!SQ}i?f00&df4vH4Hr(yi@W& zROSvS`~ILLF_{;JU|@HnIG_?wq%^@L&X&7K46B=MC9HC*SsqlHB^J0u`%Q-(Cc6}N zm~82=gAEhuYKYrME5;EyDwiJ&OZXKUK2{nWbAdrWI>MzsBtoStflQCL#GK!*S6p$N z)#r4jNtZd;`) z9i(6xAqW!`L;V%sBdra~;T=yX*ovQhSZDB%GTGj_u?zaIN~pkNtK?6a^4SV`^GS?; zu9BBHk+crsHp_rH>FFEqdjlM1aL4>hb)0AUtT=3oUxrhTs0I)<9CNrg0oWj$D4J&SL_SKaTd2H}>l;T>~ zxYD6I15EHFKqENqc@m<+@d>FyQoOO5#Y=8cH0{y8gx33#CYdVCB2MZ}DuvUDx&wqd z7A~EsysSA8Ny2m>I}EHs=NEGTWm|#ZwBM)L|NoMhapc zjL|ASYsFr*Ce{)aiJ}H;`(|`3rtf7cvU1@R_2zfLt94PWMyXH{X6M9x&R%NxpmCL} zj3_KsGmE@Ms&Oe` zNlI}iz`#@ty|Z}mhk^{2>wcr6twBxsMDGQCB`o9SDo+@~#>V z`&%jBDmYbJqQ!LxTVO1cX~42hj-olKl@d;nA1(=UFr9oczKZd&6(51Kg|wFQ1^7AMgU}k#Q25U(fv}`Ch+lpwg`_y} zKH7QD3qOaboGB4{g@_pr<&XWORS8jc3Wq9k8m=)H-^E%n`DkJVR2N*Bv+MVYW?xesdYYe1mRPd)YdMFa3 zQ4;X^0BLlseZ;92J(Wr3GxSvQpa@10LY`TSB?WbZ9w7#*yt`3*O;biSF(0)@ zKIrc*l)2q95nu0i$qPMuwhe;Eu~eNbYaP!f_u;9KI3 zP?`;2|0TM72`I;`%!#O*?cct{R6f)@|T*NU&0G|iIIY-h`sU_+MT`Ca#tpYx^w3A z{pSB4d1U@#y`z>IC2o4?g!#Tu;`bB*dDR=?Q2TJ3+9EY*3Qk=-dwSXi(-88V$T}3E z$El9PYDLKWl9Wn9G+b4XfWYKYESn_>SIp1#tA)IvUSfgi;@kn0mf(<+UX`b#A$V!E zUS4h^E0vVafJ5@?f*hl)Ux3159@UHa!CX!aU2}w#DmKlY2(whvm(kE=>m>9ioLt75 z0N#rfS`VtEcPlAJAm!{{so5S(E02&7K$m9VC_}%_R9TxLyigfDZ(6GCOiH|n+cVHQ zsHxLdg+AilC|zdEfqbIL7Nc1S>Zv&lND)>M}aWcZ+#N5TUlGgQ5;BTBCA0=s1mrTXqJ0`vh0G# zdG;F|Gb(=wv3|BT&EL$s$YfkWKUx1L{1#;`yTT>ZreC4%sO7pGg#xv1ImWflGOl*j zN6y-hD|zFJA4uVSJ)|$2l@+Y7hV|M8rfzERDsiC|c^G%t^+Z`IuB^xa1iF4v_8J{NFJ+Boy1JasGXD%Q_VDFpz1`?d!mhA8brdMj8n5`}=3<%_ z5T)H&Vy>MIeAs`*2MN4Or@z`jt=rP8-$(KWZ*tM*>rIAwF=57EZ0er{B4a*ThLY1`-*IF@ zh)Dc4Shtvp%t9GCM=v+^Z5OAT<{OvUQ!3*yeehODEnH;C)X2>I3DETlIO6E-@ z_QS2;2-&Pz2#iT%KKNBQ_JQ02i|s{7VaHqLIg)s?YbuR7_I#qL zNUYLm6G=#{p?;4Q7=#t{`K5-=N~zZ+D(Xio4g&%mPGw=w(&M$Uv=m-wMi{U=k92OQ zflRCD3ck-Au0&PBWTQxnVy8E|`l#Ef`eLwdZ*|tVQjy88zFvIEU0X@6s<9Z!ZZiFH zi%1sYaaJj2Fci}SU$c4b@7LK6;t$W#1ljNG+t4DCUJ!|iRdDdz^jc-s`9zi0uENRp zI!S(L1nMU?cGz~NS;;BR0Rul*&n+FfM*YP?3a@2rd(DK%r}1Sfcg1E{L(`R)E$G0R zAAns^#t$gbqYE_Hd89)^Q7gTxs>J{g9Bz2pqnq5}9UmBNpk-lb*?Yw-gZ0#Q)gA>K zsTfojD@@W^Ln2Kg%1BNSrT?hrPDDweO;UJDuea*AY>_&;kCK@Zc_F&B1d66bovm=H* zSe+M}@>oAJ6hRkcIXGuzOG3ZU;ErKa=B?MjZ^E!be+>z$f$J0fX zkzZYg6N^3qw49*3;@lK`!N2XHLng+#;y;a$h$`wmos=jJ)WJ_?R<2mAy z!5JsP#BMu}gRK6wxQSSibDcb4_tumsV^k_c6^^u2yE`39;lk z^zD~EBnTdD*{Dl30U>57K1T#Hc7)mRqE8E<(@uO6WWjY(f z&v3lZe*V2lvY!t)`}r+9v!DOv<~VpDpPKj~eRZ4Ofd;(>0&z!2e;l&$I9#EonG@9| z&t39Ing7(WK-=XfL#RHCg$$BraG1hqerO7LPrjp_;bsR4?rqhO^Tx9sqi1nDUfFQ; zRI8$as3wk>40lnB0cv+9DR~E!l4o>d_LLy&(yqhAxFalsZx24-GQ+XXqp_fi6Qucz?1GVt+RzhgKo$DW1jHS^h8|{n}<$1Fuba7ahKq$ zNrGi05fPQW4YYrd-W9+Jxkom}3xGr9bkKN=fn=n>!yJ)7qP zGxK|Y36AyNPn>dg`QBf>6wr^M=gU;J&xq<9!+oxPHL2EtXL7PfoMUZpPzRZm%~&;3 zid@7jMUEiz&|~oIWB_rL#RsTh$)}-S#kcB+h_O3Xq=rHSzLrWgA}Z5kP6aZpqtk#4 zHDF>Q`gNF}5Jc)S`e!KUOr{A#a}?3g9+_!67gLViY)wEn)}&IE0j7xnk9HncGZX3} zVQxo9io`y+h!Ss0uIz*!Vg9z}`ev#PThGZ=!SmRNqokE)l)OmMVGmS|xMm6t*@Xad z8ZUqa2nd}2^L6FFBz=#PnG?S{8#%GtW~&~AzTd5+jU$&?S)h=OoJ63Asv|a70vRMpY3ANGfAq>0MmF zi6k&Dy`Hu%9VfUaEX9Rc>W`W)qoW4yGBXJ0xWP34JJIc~HXp?S?iXINzDC8?m807h zbZXJ7I@hqAXiCGO!{SnM`t%wpD`y>U9%@0edHE$PXQ8UaG0dXUkdtcpN4Jv{WsVa` zbh3yT8hzPq4j5jGiXh(j3Fcry|M8NUa!_|rxy#LjK^7eTlJ!mVKLMEpe!(azzHtm) zDY~1I!)b#Z!kVJU-L~sZko8H+j5?IQN!@~KjG^gDzuXnLu(&t5)jaee*xA%M1W+aE zind8jSE=w0_U~%e;%;XM^q>!^Tn}vit6|Y<{se>>BxOwx zp*m2(YI{c2hTzA(Rpq7pkLhCOy0{6X^rnlCQHpbHiT?PW%R?&pY1W5bxfpg?X4>*8 zUhYC_d{K{sWvSJR=UkQjLek2pYlJ9dBlk)Vx=dXta}v^N#}pXwU!?;JM(0^lx0>6D zY+)0j2E&|X#qDdjrYbRd2&++z1Yyr2l-IJopzyBqW!smw)8wAQz1#vBZQ`1(a=qKn z=YZIq+0;{lV^~wnmjRWI_)W1K{Our2{!D>YhrmVIWUIpQiWzGmGgonI4GTX-#lT_! zO7X+Aj(IX4EEX6c;^S_2GhR(x|1=v>)yMY9qgrL2UKQ#X!Jo;V3egeKwjygucA*)Sp=Wzq10b?ad`|9?h1A6WvB}v!p<%- zQHP0s;_{|&pD7c;m4^^TsHP8!Q*+~^&>2swu%Rf9%wI@Ywjy(5qAKs|p0E}rz&Xx` z^6y1;sJTp#PGYf4$#8N;6-}>cIdM%});e~pq{}s}mRP4ubAMCuKG@ef{GY!)UvZY zUZ`T&jLYN5<_p6(0kiZs;5g_SJ3A~7CcYarW{Sy`O3Hy@Nbbyk@dTO8hn(4b=g!RL z&wtO@;6O(()ox*}XC&Do#4N#4Fxh?>rrgRhW#?f69P(!NGN#YKqdUk$T_Cl_?_hl) zp$l}`^#U?+(LdCRTZIR=0$?nRY{y*OL_%AFfXu@Ja^HGWl8Pau{hVM#iy`whEx8&c z?$An-NR%sJfiPmry{u4hlyOF`SZKXJ$oiJ*5--q^B&P%L1mJKaD0VV(N4bElnFub(RXN(ZqUpg*68RQ+#gactUdv!nEDjK7miW26=oEK z@0AJ^g_fI8$_Kg2jt@l5^rdzf07Mo(NkQV^-=A$VU2Fu>+-N@P@<_-nopMKbS+2q=Kzi}#Y+qWoq!OBS9w{<$1zG58 ze+dgNQR&j2$6Cuml<1dSZEcs8PP(F72>ogqFQ`Om(8T`tt?#5LfuTR#8bLZg%{YeZ~IZ+?9_;QW_Kp(TCPt3pl^%g<(ge2^F9 zR<|Vz&60`8=((bel;n|11t+Wlf;7UmlrF6KF(F7+uAXwre1&z25{=iCe#9)QZn<_) zl7Y|;HFZ2KaY3rx29@jqyv*8)`c)M%uw^Bf_`dJj6z?4ER7=RtervTT`l=n?@tsj; zD@J>})lzDY$Tn!%iASY3MYm019?1ztVo5nDz#7Lju1ZUAg+Ld_VX$u#BsfNs+N757 zrAB3iYVS0JS`P}vip3~FiWh)8T8LvK3@xl#8T?6&KXWS=}g{n5#h@cx?q-!>lg>e)x&q1=)jFbm2uWm3G z*?`$^jWq%^z9>vYg|*EM^00n~Su+3Jp)1+D80O{&WUfm4)(nBL1-{0Y4AviQZCc1Q zUMQ>&bFzyP^wy^lgzr~M*A`a|u+P;UvZ9_Jd{>p~N8ThGqA!MLU%lfp9<6`;Yy83m*ev(3Fyh*uf;B+DmaLi5fxH z7G(=@s@gA^31c1-j*;%V2I%XS8+VmMyp&xMu7c79RtN+o?@x(TCr&(ISiY9Dym}wV z+~M3WrdRLSv_>nJ+qN82x*Uk(aLzIQQ@Sl`%f7?v;^>UNNRY||Zyk1#OAi><{V*?F zwZgD@jcrgW+2k*;NzQlg!BqDEj+FS1A^iwAXbOX&^F-SuG{3;eYCl~6# z{d_fF35;Y=KX*Fha_xpivBoY}atmAdAvwkHGCIvPaw(Sup|zW3!wCjYzO!<9NhxMW zXq(hqxLMvyGz+PunQ_Tbzqp9rmCDyhK9)VG-10#q$Cyr+uOZsxqzCs>cIBcQ)M;H@ z7^Akxx?S<95UlNIjkV3onI>9E65pz)3%?c$8_`B?XOz>HqhHx=pGpKkR1_C~uFmcMC&S4_sy6=gaI)27Wc*|YcqOgd z03v&?B)NPEF3{Yj!+ZGepm+wDOE+zGlTL0{p?z}D%GU~@@#RoKq4{FZ$!U?a8NZ3&kl~vinM+QO8!6N9mXQ3SHnLUi zJ9YZ>aBqxtVtKmuZCZ}D05uho7Ug`)3#v+3E-@XOP$;tBt4J^(#E~(460p%I7{7o4 z-qTSCbUQKS00gCsmqD%|&7y@ygqDCja+_0G*&+6(C+TsD1JADfwv?sTb!^0~ZDCRE z)TS?%=i9!b(zMHL_bEn0Z|(z%?D5dD3G^o!FZN#mEVHQcxlEE$WyK1txrKJ z>#a|%#9_M&ddjU|FIWkiHzpbQY%QXVd_&=CZB-~Qt(S)9chYWoP*dBbyQnd`z;T0V z(%J$|N6s~>>>VZjftR;ehg&J>Q3#!PR-?Y-0e-dYCF*-{DSr-gyYG;$)eHlsqh~Kk zq@HhBVqfJ1k)jZ65|gJdVE(u;$p>iVN_UCMzrMpf>10mDL`gzx#^a$jeEyNL62OB9 zJn$?mq`25jD|Fka_XIp6J@hdqIw}@p8E%YAT92Z&zujBecy|yc%izKtbdg(i->WXT zYJ+?(tVj3rBc>}sKoK{znAs7dOPJP%-ia`*yUn{PHru|G9Imd82PG8U4#V z_v3$To(mFnchFZ)2T6q7#qSgW?;NZ))2u5`o{J=uZ=`)U z3)jq}pZN3Rn>`Aooiyva>*pUIWJxnNhDkqY4szEhmDw`0c?L4>7b2SG%)H{qe#A`3 zQhu^aN$`MtOS4{cPZquw9ZqJ}UFfZr#q~`gb`^52045Jo#dNKf#{h(Zk&dl`Xs=1{^E{ov&B&Ae5dY`1drZ9Ah+gS1tU!4a!_Kh&2&{dWO|bSmZ{ ztvxeb`FqDV7xUoca_4BW)PyD>i@MO0dC5$g5yw!pz}zsVGcWwm@y!nWd=gku=@{iNwT4rb|O-XFBvI9I)J#mtx57|;N^^5XMNaWBG!`4GWX!{nLa;%AR< z;uepK$HS8l6Yd4wsHNxqUFi}$bP8T^4*YVkYo7kahqKBaMA2*J(p^C%{O7FQP_*1 zho3vXnZVEO*2z{JWXnyXvcp5DS?~J3W29LhahmnrJJYQH{I|?2{`PSM8eBMk`GND7 z7dEax|5L|MSDtHb4DbChNl@RoKC#|eZ~g`UZ}_J79oV@3LiU3&U31O3jo~{VUSDXD zpxhW<{owjveCOVIh&p$GI){>9|*qqcE<*Ec@C{x$5^!Hw&;e&k)$uY=gH3yZ^D zAA3A(alvNOrHP;UHzmjQ*J=# z7TD1mSJ|Ju@5aW+ft;w@-uS)iW1P6TIkWFR@;2%t$qyimGp$4CEKMb)9q#(3x2}K9 zmUPZY+*?1qK|Lec0f;vw@+fmBr~_WErXZ>*1Jij44oe(4*jKS!uPP;jhv+uMk#`9|g=@lk2c641GOR7z-o z>wVi7{`&e?*D)huzw+BhsAKn1$9jT&#pO!};^y?xB=H^LH9Lpa|Qo>eH>fM^y~RYe~u;Ue(G3`G8JcutC9P{Q~jLcP1?hq)i1;e z1_yZhrR=N2YG2KJ)N?c}Z?8x8D2V^_O2>!5w*L26yBkeMbT?1SnZuX;rL; za(&m^-?#oXz9r|5nl66kM_~F6$u(&S`dNrU6_3ZFq%Ewz3j$J1pnRRJlR5{?V3$I6 zT=tKcjsLpuUw^UvG1vB2{*Qgsp988tR4M$c@6O?dM0!`@O~5`?z{v%H@#lZIKB_PO z_s{<;>dQgb7q{h^E!0;ZV0ZoI8`fWr#WEdw{>wi|9XjMX)Q*6c71!!9M2@xDYYSa@ z_}Kc_U>_YYip{O~3F_Km*EPJJ6BG}S^GXr+bkwChu3Hd#!?)lexdov&HvWn|I$e>U z%Aw{$wMY$XI``{el`X=(`O3fhJ?hQ9t~You<34&=-M`cm#!&Y-V}4r3C22a6 zKf3w9B!=}ee3<}<617blGifo z(jmV~PI^MWYD@hRw5(Edhj4bDNH)E`b!7cT_wOLwJwNx?segxS`p2XuZVeTgjyVAH zA6oxf?D~V|Lb^4WqHZ23b+c>xr?#}uag365*Ps9T`peL-=YRfps9*Pb{UX9|+WkQI zZKterdi`rMU6=aQt)qUo&_Q{u1~Rc7MYUzSCY8q=&PQ%re-Rz}O6w=7L-%H$19XPp;S)4V}|T8qziNkRM^aS>g=?Z5op^{-+$MuYpx_k9p_fFq;> zFzJdw9ZzX8R7bjUeb;CI>-x)ipdtQn&mFK8j_|Gjm|{oJe!Fiqoq6+T*1uNz2=?p; zo~54AI+poHHm*S_fJfG`Lh!fulW6m+yCtK6R!^6H?eDC>bVI*bl&|zjp%%C z*Ygwi9Mhi`k@@sC`qX@)KYhjSA6`76KkdP%uYBlF-oIu)eHB(Fw0pxBqjmw_o?AKRCYX^{X(S-a+4WpW=6SQy0GBS>1&_ g^dUFKAJ$@B|9s-MyY9H{OZ3102gFO6E@UMF0Fip3WdHyG literal 0 HcmV?d00001 diff --git a/fsstnd-1.2.ps.gz b/fsstnd-1.2.ps.gz new file mode 100644 index 0000000000000000000000000000000000000000..f76457379f4af6bb8a8c4d2d6543fdc041f5aa89 GIT binary patch literal 52041 zcmV(rK<>XEiwFqRw|FlC17>q`bZ%rWaB~36T5EIL#*+PxUoq>d?1H-zhi^$Pm+Q(B zDeGQYl0`Xju9Xi%U`Qec0R|6A49ow0Pxs7#phWpPRlBuY6-Ri?OuxHNH~7=PU61#V z!*rteyUmvO(@!UvRz;e<7PBm!PQ|^>@+eJ2yV*K&Z*hOB3jJE#mRfvJndlsf_QC7U z;p=`&w2zMZSa_NSe;;wX6f z^d?=XWb^O@hebN8kr|iEWgKl0T4rgG>w@H1=FGn!`L5NB-gb}d^;H&XNPC3C=~rAh` zWxDi&GRttLed84wRJvK|eT$}^wC8kMB8-AUgym99h@vOQC!*UCp~j+Pna|S)5vM9N z58ka?g5Hb$wg98Cc!*yh++S5!^rihJT_WQ#VnKp!dZw=d~cZmE8Luq7>_U9pfCU=i%60 zUSGJYi`uiZwKvPvy@sFo;DOme@j%Dz!X+TF!Bz44`I{FkmsH54t+xH&!9FbuC5w1{mOE6p`M zt1rF%AQq~~qDQ-Pxc2bKmJs`f3|FbtXi;pAZ;57qCl#Cn`fD1d_ek^2-a!uQtbA z{35L*a(bvUJ*-74dF4Vq#yXi{QCr}-ev~7;x>O4-z9#8IB9gRNx5?7*OjCPJ-CcXt zhVxTsca8JEtto!+&w24TxP(F`ki#TMLn`|w5rGvD-;k=FTH%?FHUdHlP76<>@pL$< z0)6;ycyxC-}8pi)>@>5XoTtvF&S z*;Viq$dK*4QX8|$*+bA!9(O5BMuCtnVNSBt@-=1XfYnTB}9&43( zPtKvEk$BcH(zi@6fwDcTf0yhw=V*7{ZbmdFrctundPFd0HX zss%1{1(oyaESk*=xl~A2v7Xv1^HAmVI{zw{ahb~i{gRUN)pD+(Uz`!8p+qLg=kiaT zr7}&lEFMx>%rmX!6kdU3ey?R7J;Jr`bs{yNnjjb8u$Zl+7ZG0~J>|L7f0QalgM@g| z8Q4RtpmCF`KtJ?Op2$-#KtX#yZ1S5E<0`eV50y|0*Qs81H(;2M(wQ@Ta+1(hnQ!QiGyH~wnVXubr z!q~%U!?>}sS(RIAeVBVyWU#W1jm?e?C&wF) zmdD23jw=Nnv(b)+sC|yBq1in&yN9*i!)n{PS#xgIoY!OKyjnCY=JL`IyfW*r%=)X^ znOAm!+vP!XaS<)!mAo?E@X74`WcGfl?fq1d`qjL=ou?Tb0=|y&1i#9qGMklouWFl> zA*`x16stnPo2@1gEM~VhyLD~1uC_&HO=Q+YwKdU3CJj|2hG1&er)GUxTc6qm)zLs+ z5k0WcQktEm*;&?hmerP(d0CJmh5jr5mtDz4i2{0 zm}i?~2xDxopeJ+)Bb92XM#H(+fCTMo+=d5ZU6f1j-L+j?J&~i9Xm_?Lj7R$^_7bJN&wcG?4R<|82^@ig|k z0!5^~Ilqz;6xz*BgWq>VyXEazaH^6>$KqodB{6jM#@sjU{oi8Zu$g8JP;MR`dF_7R z@Z-Zp3ODNb$M43sH^+_6VW-*e z_C=?4WC@+z5+N}ZBdFkZu0^`kiBN>Jkmj;z(rEWuqSLkOJs%zv@{kh+0DTa!XGAa` zJB_}vKSTHcm0I@ZDhC`Ry@JYqv)%Xab;H}IHu}tuu{>k zP6`E{Ek&TlC8}6bgXP3ev#&UPrpbr` z9+)rEw3x>$x{laFYy;~9tGV%rGanuDL?Z%7Cf119AyX(A{0Zfxq3Vr(pEOB3iQ8`5 z<(B6Mu(53nHQgEKuz#GVg3?az^r1q6CD0t3o>l#vC$Bmao&lJHN^e7o6kp6Ecn|PK zu@cl8(kBpO5^~drEaEW2&gjltECC_i7Z9FuARB~qvhz`XV|=RHu?fcipfcou&fy+^ z0BRhyyl&sxN(`@S>Ads9>3m1ZdoiDDP!zpGa*QXObihWxP1-e^5o|zmh~BENGn$|r zm89^#BrzxvzC(u|4a7&v{zu+(c0OI6e{L8T8MXXo<5-N^=HXF`zt*QQ^ z_$;p|&z`{DRbo$RBM7&3 zZMIJCkIUq0yeIHSe29WOFH3EfGS4p0?aQ0%6Jwam(Rc?TyT96f=k1B}BxtfCjyh1p z*m%g#e8~9co8FF7j%hg+`;Y$ZzoQJco9#CAOzJx5*~IYq7hZ%CIQ9_^DJ6v?`|e>} z#h;<}+%}(K;UrJ9A}SY_MVn`jq0y9+6WS1_G3cSXn1&>0Zb_R|haM7SmC1_yCd&A! zDQS34$+b+V7c=#OvNyUFq`8EeCqv;O%5}5a^(oiH85ji+rfPxwV2VyvhH`X>0A&;@ z6D>@5bq)sXG_AfrQ?`7a`B?}eh#fU;;0>i~3Lm5s^6~r14P&5PWFI1%*oUM+=&f)* zve6nUs?P4CKnuFB6n0|N)Ni*a&W)Z>1`*we^qz@#v5mKk{yhI0l14dy$%cu51QOCs zkvi4)yFFVNSBm$X`L%*&=riy!B7qs5O^^twTrH{Qa!}*ws#YVnyPzYKZc;5#b9LYH zkLA|Lynnf26v`(RkRL1o)1eXOv^OB>$+8L6WXnJm;kzXTO5x21oRixAXgt2XJOxm6 z$qRXpMKzi>rI`YUiUyh%q^Kfy`Z74Kt}O4lwpdvUG%Mtg;9#S-+#(puvFC3q&eT<- ztprZPs|jTp@ee7sYs#-qS&`Gxx@DOy(_GgUyqjQT%0UeTf#ng_R zTkMgfgT56tFDJjl%}F6>rE<+f+AInTvoTEv2t>r`20Y$TJ*^|{(4>}mvOj0C!p z0GcK5hfOqpOQ_`_INy%2en}NHgpE`Th?+&au`}-orwzM-ko~p|?tD`cf#(y-8HT8h z_bS$nL*6xv=TPoa0jrs0JZK$mCAppI;Y>kxVN<|3^tBY-qfV$&nk_Zl+7aFVBizc9 zhu*Wv#&zbvsjsIhF#3f_Jf1{6pM;D7+soWxPd6`MwAAjI(BMWC|52Xx+Fg@p?T^1Y z+db_rNnko_9~xNfg3Hz($3*O|0k~}P;H*Ucps{A|u*jwuQ1PoJ+W=lM(+1@Axei(^ z6D1UICatqOM2U&oZSNv@Rxr|8p>GtNeHjZAloIsi!l5LZm|SHBO;UEAAscOX_mvJI zbjLc_?H2PyIocph0|TN2atyex=C2*G{+mP9J3y|YIZMwQ`x?Mb#d}yyAJ8Z$6`fn? zs>eeJ=sik-lbFGC%1T1mxuElE4X5q)pcz(E5>S@=qeMdGAGA4ae&>&E@6*0(n1;JI z@IEqo{hncO&=X@1X{hD{ub(lOE{s_@n`96oLRXnL#fCr!1oqL>Y@LnTKBl8@(5Q=3 zJJDDfk@|j<9gJ#lbxM~{f!Ehg>9$&Y3crw}9tGrPvxTPA+ATSRO5tD-K(m! z_WZXdO}%Oy`$#(U?Tk7tX2$gOF!P&YUgmErLz9aR8z-J0L&z*mq5y~@is|F zF(8=`V5c8{*?Sf!%^b$74gqYjMICP9Kf(!f#<>yjB{zJNrw;5U(d<&w$XMs?m*yMo zcE9~?d&9iUQ4VC~LJW^8R2a4Q>+WSOTP5TVHml#QiV4LaH= z{XbElDFlcjX@0-G-{>42GzSOb0PZ&4#z(#XSNI57w(qx_;>;9MuH(p~H!r{=(Z%An z7*kPov%8xL6K$p{n#9)&It6o_-g!ZVD(orDK-Xlv?WDPx z*;eVzRa;Bj9$^s@c_0whowvIW=9#A*b<+<&%tU0OO(uso7~Wk2K&bG5MvVNq609Ngca})A49r z=Q>N)IZwUnAk~3dlo2Bbe7117lz{wq#{@JLwY>v^ZS&`YB2 zJj!XJ_C3tjt@8x>QsJJNFkpK|Q^2GeCagj?&xoe3n6SZ$YQ9Ooo7fXtAzdKcXp&Gw zlpRgVPROv_WZI95R5@LnEJoc*I7^ordtl4r?N(cFdLAjRqJ?f3%&A-jz4v@anqt_f7kwg5(rVFgHTcO#o$3>+Q%-HD)a};%F9K?G_^3z#P!9sMa-X1u)9@*k{92^aHkw*pA%;MvW^<;d4ew_Zgox5-SD1%8O}; z!6CDla#~9`Rn~OQLaL-x^uS%Ya1P2L)C2hIG;3d$-f@W%K5{VvRBhb)hVcBhtc#9- zb}a|M{t?EFpqQ!Kd(!yx4UfRM$L*s!aXScm}uTB$eCL6V37QBkO zu{E)O6~D{1VxtLos<4hAcR`6Cw=^ReQaqmQARILkiZKCcy{ouC6m)e9bzLlj0OB#G zUgYk8rm@fWeerg^*)=*!Xz=1Xb*Eub_I_7*Igb$?Ed5O|XJ`y>UgTjw#<&YoftD;K zQtA6{sk&xg1@b zo}=vrQxa@`vx_Mk-`+bsP?D-0ROK91PRR+VC}^icBq#{;u@}K7y@C3#wKyZZp6<$m zGPIIqxUcNUTs6Ex-L!$@%pVbwempk$$CO_%45~tsqK4hLlE4bIp)R~ZeEGlup-YOJ zq8X+hPJ3gzh}fPY1QE3#%v#sPP0_jj5oSc$$Pw;d6$~RSMM~0ctXS7IQ+ujy8IHVK@Y;V30EnF{p5seOfe_1pIpNE*_8I3iWUFlv4y$oww zPH9}!Zv0(0Y#NvcEsp>r7Wk&nvH2wc3JxA-@T@J(PWnfo39IeS{SrFet&p2yp~-yM zm~lb6UAcB1YLH)O^)<{6_jfc8Cc>* z6Uc3eHKHV&uKnAa-C#Rz;>|Lrx7`vXHm;%Eo?v3z2RShp+x)7*6FleeH2j3H?aqkV zZ5DY`)Vdw{eFjtDxR9j6p2n7Joc+DaEod;61rdY4r+oD=YQF-$JHCZmg9NjBO-p0$ zGr0Uvz@6-_uL&uSm;;%tH0f$N`7aCh$fSkPhKSS7`)BK3R+f&?$_FhI$(MeQ@z$#c znT*vA7OgW9dd9LrECT#ewubdX%n^w40`1n;9J%F)xO9(S zKF$tDW(V=;4~opXy)9qJ0#z90!L+bqks!Q1n#3^N$?LQDr=FkKaE@$iH0zyFGDx$b zv+H5f^duXQLEe*`l<$*riBa*pGKY}Qnj>5fD>(UHfBuNpPyOY%-%nR%lNO7e+q^U? zkwtrn!_DsU1OfXeZu6??@SualLeU4wdDT`s}Y4j5Z?vszSeJ(1D57h-G zO3I}iB!Lkw;1PajH(4(t#5r*An8L(aC)6Q8Ishz%cLCX|WiwFJC~OD38Sp7N!mV)y z;0Sl@xFM^_Wv5dK(->%2ktu$B$QCCri2kuQD3-RtPmAxT){?vN8G6d?s3V0ptaR5* zpmfUZl#R1m;3VG5{6jvfn$PnZlVY&sw}gr09(k*)uw`?tc@2v5=mFml;32dn*-Nx6 z+h~;j^z`d!6#lF0`g8625&~7>;djvP1|SxA$vC|=;AF9TXwCt?V+HUh-lSIft>R_L zY?}+7uh=3cAMKKSZBHK?AmUDEI34WVVG~QR?3YUdCdl@tU0bP5Odfw~69unv=riz= zjQs*ng)Slc1(Ry|gUm;7tyKiSR8w~WzJ_~uXEY$t$2D;SohQgy=*@BsfQSd56yc4V zf+UPVaUH#3G%RB}U@rj^Z-;;>ab3~8W!Nx`{-b9hjLYvW6JnPfi-W+Z#p0mue3m;1 zG_*tb-7NkDz@Y&K$oFYv$}V0i0|#LB`0-R+UpWe@yq_HA%?{S9`&b%9tL z2{%t4Nofo+8}gP&r*kFYKQF~LevVNX4I(AxZmlpfMY1)|SYxFW0<4BMa-H!g zz14*3W!2pH<}%(1y6k#KwKIxEDc3r9MKgyEi8u&$%XTTkPY}N)i5E5)C3Np$+js#Y zdK9yUhU4UR-Aj8cnW#t9J~%?kwJ%EZ>5$l`IIyOyE4CD0Bt9o#@Y4`X!R(ehlc)nR zV|p!lVao527i_z6csewbeSsl0o>V&C_pmUruAz2k>oKIj4s>jsI}2rDez3~tH|}MR z0iL^T|43#6{}wy@ii6JMDC|UM6*x<-tZzI#&%VWg5sdF`o{;=I=kQW|w+srK2!AdM zHH3t@lR01Wk+K4ojsi~Jd~uAf!euefcQtz9#+g%ZG9mC`IQ_v2)e%1ch@zv`#Q32s z3-S+5MX2WCkX&4N?}%S~%rE|Sjpc|9CFQE^EzeB|6KV~_UAe8+1cSu!fsoiX=kpTF z3&5+S_bD{UPPrQaW^eJ!_k4Tzpj!G9jO-7u&pD5qobTp0y>>NWO{eum;5Mpr97>c96flrw*CGH1TbSY1p^{i+lyi_{Jw~;Med^d{w*w1Z140BPAJN ze|=W_i_8oJN!E;T_tqX`*r9~Kh2G%C%iMSOrfe><)3_nU4$LXu8vbM(9F6cT$)WST z+)fD19#K-(EPzpeO7q|a&GpC5V~n6fTpI$7QQBBS6hoSQS1a;LJt?c8241dPH2c7BP7Z4u18fT zl9_X-%q^OHG>1mRESN*J%->(o*l9Xp7-UqmqkgVW>$(Vm3v1_mY|$3+fXx87LE&1g zXIdjuCNB$2f?~mrn&u1kdhtbGM?M)QCPu{X zLSQ})$3suRP+oJy9K)^#X9U=IgpnqKMO|0U)uc>GNhh&53A`0oy9Nh_;OEj| zH3jGhkW_PhBHSBbK3Jic2X#Tg*lMV4aO`%T1F^PYJpKbwkdJvaGcJERhv@~~5X`J# zVo7Gu&##t0(npsa_eW%8!uX|ltC9mhBbw&4&Kg}+$&;?+B}qfO#6xeqF!9^fvp zd0>%{dWKNJ;P$IUaZDz6{}l7#b0k;fP+Tez*S_z9e#U+9J=kYdfh93R2pL8Pi?0^q zrL`-eDo=fI7~g2JoId!nDXPt~h`Rv>9AOH|4&8>qkCplBoCdcs=GPn!L^#TIiKiN( zM`hTc4kX@js731WWZ26f<>4`4w%2~q7)-Rz7Dtc!2*b#QTog+vx~?> zcAJ)kQhT^SU;w4+ft`En01i~$`w6+)xwqc<4LZXO+F94KLBsmWmtaOcP$=qZ2X-15 z9T3tZm}db@(1q-sxDpM!NtR9mS6)i?+@^cytD3M92=jJil?FH)0a`{~XNc=toZkps z0K>1qU84dkm9e9HK#ank+`!ui6|>VY)Ky~A zH2W0wI;13PH|mv8t`VVJDWT~Bl?NhO9x3G(oj7He5Al!7T!4>1lv`)MJgaWY?YGYU z&KGHYe@PYnXxgQV;yHL9XS-`~12Wva2S+k?AAbDw{_I`c1(cB*q&kvm_lMs=m$@Se>-|z_ViNGH|M(&Su z+6~U2fAAX~aRIGCK$_W076Q7^Any^yTIwBegrbY~5MP;m+_TAKx_FMcDA&0w#O*`a z7}h9-5pl)cs~x2CD%IB+Cci*52BCqJR2>4uwODS5;RT!8!k!W0XNv{6Qqw^P4afQT zu^x}=aT!`!u*JY2bRK=Z-d#eexzFxm3%^q0>7(2{r(x_kQ07DB@CsDLDd=Lzb4e?u zjqL{bb+V4n0acEGuKrXO6&2LLkHeTcJ&%e#&uR&La$^Ky!W~iM+a(VZMvCBqW1`O(A92>_;Yj4&)H$6 zy8@W1Qvcr1?#1`cm(6d*w@{D0a<=I_b+7)s!y4xx)@kzHkKg}%POZg&)2H$_e$9cd zJ~pldcl-zMC!iT3!{IFGS1E{)G$oTsysUQD@w+sB9u^mz6t%zn$0V zZas&T|8tEf+tv*v3G}kKEc3N#AAn5G+!J@(MK!;TpOq{6^z8z_2{}3rED47nMBSs{ z?gG1i_x9b7@g)>H124DR5Jn8f`GrGZ?npm(JNnvfaA!+52A8mDOd+{XWw#{bTH zOtrk_vKXiez;MB{JBe+>HP|sDy!7qrX3Y~3IK=WGhr6Oe+ElEdL%6HKd!IcfnS%)_~UYS zeeAZ9G8SgZ$9XS#-b;m6}G*1sXxoJ=zuh3HU$4 z%D`pP00>~@ig0ssEh_WoKr%R@bTE6gg)?@z>KFbE)LwP`gv|7O-EfV$uZDX<&vNG8 zMYK^aBXc4jk^ic7sP4v3_)vQi%YC^@(hy6KFLH{0&)GVD66W2W#5aWBzv4=#+?p;~ z#-$@ew_N+!jGo7JUr{+Yd4eswWBXufIQH3302E#*5dW2w zFFh!S80Sud;!;9A0+pB>ESV0iwlm>Ud=VjY5;3^>>gIjs6yssOC8v(S=Te1y5t)km z91UPZ;JaJlfFsk6+Y=}aOh01oo-KiK*t|!?w5M~R=VEq&0preC>UbAIjWU>>>$0F$ za2+_n&nC0!{JBKamqcl0bFdeQh8e%O6$DWRz;ZTqvAnwInTi`jDi9@K=F8oo3XEha z;k<-{eZp1M+1~-YlpW)*Og&rN+CBHkrQM%fuqCarB$|gw61ru_hfJQqbyCx(-=gi`9gJN1+;+{mY>kF(im0P&Qpk%}}SCQ_*PgTUK z%4GGvkl!oWE8^K(UeTO`t3|Ek8c+!rwI_M5UTy+4J)D(aW2gdT_x1~!$YqUwQlpRp zCD0~&l9?t^)no~nffh%Akn+i@ww`x3Rn!vBdYpxo-~Mi{L0Hje zK5_2u>~{owxzcXie|?mkgdBdu*^`h2{g@|$x#;}R;p~M@zP*=4%@Ol zW!NNIN1<|sgWqjNuO*{OHr!~B843$xy>ZuMVa|fB3m?l_Rz(L7EfG_JTA6SkWzIXq)h};*Ra6Ac_8U74^_-7)Hz&)v*3?kg zY4iwOW*krde57F+aYiU%n2}lO4P*t#H~Jjr`8t11dkaxgK@^O*e0bVpV&=hP0kNph zyv(HGaf88rp&kN?Q>+Csfm5w*=~8wF1a^ z;!=&|j8u*;O)VCQH;@r!i{PYUD5luwAcG?p3wA2*T#y31CYsQ^@n*ucv-1ABCpGjG zOnA3lU`=hE#=EuuH+0jTr@CT3$~)z?Nf2O7`W%A+hI!BR$FO%m+X+xi^qUxUq6aRt z7KL#SBWoQAr za?2kB86S45D64-8^%M^V+pYT{lWs^!G9QOJ+O|dsgC!(YF+^PhvO@o&vqL9`j5@>4 z+za!wK|a|up!4BjVU#w-JRDNE{BY&v`h2qmvstV8r7uJ+jCvv(j+8*j8Oz+6u4IogE7F<}dZITAPS z&s@*vp4iwbu5hL5Vz`LRKro>IwDg>2zPb3f39ZhddQNDa(pCI-UORq9jw3bdi*4 zk%Ej5!N7se22A!FfNEkz4V0fjvZhh0i1@myKy52W&>X%7P8+v*Ttrl{0FZ~)CL(2K zBgk2|Hwui`NwT$zivh%Q86(8l^CquvsRA40gp>r^r=c4S{yY8ReJh@G?#0CGwWRl7 zs~n=9K$Z>nBhIAIBn|B*U;D=0c9E!zMUDY~E0}FMSdWuAZ zY_q_JrO474uKBGKNt=((ZUN<@Y_RA!3n(2InMhCjSM=R#aS1lbl#A?H80#mF1# zhZNZm0(brF1$vY(k3UKCe|#?qKtK*-$`^+l;soYap%qJWi;_4vNm?Y>7ZLS`aGvOy z4oohjiUYw->_+@27HU=~1x9m^W)RvuPpFD#ayll#l3g7?Y1*(#1PR@`s(Z2e)faGEK$mLJoHOeQ3H7nz(>qY5-PN|kO~XIn?eD3g@m|bMVMBq& zx;Nkr)=ciCE()wRL2OSp-lK7g5-?1ttlEdKnTEs{p8%pAiENo+bssU{jw1h}W8vm( zZ^k~e_StiDz;VIy5eqP!?1qGZdZ`34B|`A5K&!+al2LF-!ZRqhzCWn6DdA})DQcnE z#(G2UO!}^FWk+&YP=iKN?t9T|(PcESg^}&?Sk2>h#i4PytCSvuCH`LTPFwMfu?H}^ zG-546vAVBzv~A>=Vi6Bn4zuKZw*pKEvY|jwk0U=6A4E0?I;oU^BzBhAyI-P#+dHz! z2!dbkj&AcwCz<@~PQyM@*?R4&2?F;=~%K(v# zYQ8A`a|e+v@^>mkTOVPW5+<%7`$I%(r+b^aiIx(k;tgm&p17TETWs=@iji0W3(Ip* zRq>I-w?E|AVm}=d=b~#*52COYN=!&Rp;+U_Efzi#YUvS$2ylR7JnrxKvQq%=fQzt3 zz>9bYKGhuwwVre!XYZ-B65y#CQ34z;a={<9>0FM0?bJirt#fKiV0}B>mb7h-cN;#p z;gBW|s6PSKg4dbpI7Y3i!5q%q70$w&iBfr}K3X&*&M%89R-D-8I$v%P#RS=+ar$;K1Wy#EQ61SdlHih96g8UH%`H}o1zvJjOSp}OO0z#HK%BQYcWOjyJ zf#B1=!Quji!M>6dKx80`As#P)=!7S_YfcHr`da5B7QzaTs4hc0k^)KKC}FCnW5a;9}u7) z4D@blouT-JV-x8+%x^~3a5R5EN=ArJLAFOFO%PHr+!jn2H{{BrWh|K5FvRE&zaxad zAX&q!NaCpwwgrtb+95nEVo5-S+E*IybpfNiYiF7h7o0#Jnw)ByzQ>j>?-e`vP@DL+ zgn2P~5D8C}kFlzvi>yGm!hR?)?m_Dp$OmvjS9}xl61#39vAA+wuFAi%9g~wI2~`Ie zEM6ir;hK1-uzm^?SP54^*u<2|ck$8kR*>xw|HQmO?cG+(z6Cx9HwN484k$`v-C$mO zOS}*!Z)Hj|YmHXhX*%V=EfFCBM-TYS`~0YlC=_(gW{fXFqMOgs>%jjrLV<$T!(T69 z4BS6Zr1hq7Klp~L*?`D~&+Uq7fcHD`4sJ;En(@dj=B+i8eE!APxhQ~)zZ%d`W z(q4ec?zV{E#E#ADdbipz(2~-f#H>L)w>WJ4a@R;@#ljgZZ6W1_X3`9Yw6`TM-R>6` z+bxtJ<3a}%_jbG6G?b+|WERld5m%(=q@rXH-42ujFip3|ZIx)efv;#cg8BmX)Ce42 zTH9MPR@<-~qy}@3T^B+% z3{-D|dkUb?!FF8W_@zA}r_j^PhpORLYcB&&JJi&2o`jSq9>qzx>IuRI@JYXcFT~Vn zY`FN-$o+4o`GIJNr0k04G_sq4_2OpKhu7!Ad)OyaMn0u1SpOUF_ z!SOj(b~eG5@iM7W0D&99+JgNU#Kb8xs=q^Jg<~VF;DJt5pXYP=)qK7agDH8CdQ7|( z;f9A`t!fMa)9Su6x>AJoPGz4GEGi_A=B5C054U9~Q3~Z{nIsV7Ez`sCmRa2I|B>;Q zy@)(e=ugv3!GF)D`DFMUOwR9<{kbBpSr)kdGdaLcT@VZbKNnXGEDnp^JxD>e}z8r6T#ua zM-Im6fN@g{YSER#jKrp3o}bLW!MhH}sk8C*{*iyOze1nr$&2ES9z2|;8K)s$7IJ6) zV}xKFRcPfM6-8DjsdJTroATrQ75apab6#RIr{|4N(|#tzwU#KCr%anKms`X?i;x(9 zmQKSb@U!&-exMhHpe{XGk(@twA(Z4n_${mf?x*AMZu}Iv5b-B^&JswR;W5)eDpuq< zr34j*B+rnqz&&PzbTl>(^w05E=o39>wdNT!8>JH|6n~Gl_ogbz0tXmpwS~ZfH>%{> z@-u{Wj+|%bpWr8rzrvsB*=|pzQOum-GahK+2&eGOh@p+NIfFI~-wQLC40O-3~ z`+PQ4d1BKNg6$3DSU?;c zj8~~i#4chZTpK|5 zU`O7sxu>~3bw?$qS65(6!7bjyoji1p0wWeBQa}4>q*OKlin}B?fq5WIt{bo~=3OZH zC3#3JVkFZ3E2A1FvKCy-xTJLF_lZ8w6Dpb~iL3(MPn;GYKcq?&aue06K}1Qu;!^H0 z4-HJ76*6L2H6i~3bn&mAr-~w5MrNp!3wOt}1!P^^7Al?0?mKmF?M#!omvI%^r8AFI zv>TxNf45Y|&9h2wgH?^_B{AklkmNyO($<^Vr=#RL_o01&TJ~t^?GG4s@n!Et0(1Jf zs|y+P&*!%?N z!7>bPFT5dSvnap}_zMDZ1 zKJ;>l5FS1DY39fHq*ZEoMwJ-B3RAv(h*S6%V^sghrSR8>%-s-72ghcX`_nJX?rV-l25ofFiE`}u^!=iB~e+o<3L9}HMDWl=#fnL zXkvD}?@5S2cao<)IpUcqm?_7^OhBZK>^e6F07yW$zpLFo&>}q1l(XF`cbI^Nt*6{y zh?vwlyTXN-N!ipImC91oj& z_r>iB{y+W{)e!2UaWmd^sr%>}UAw&+fL|bc=NWjv4F{5TyT_-<-j8;TUtI4n0rp#S9$G0lZkn5a4`86MLKtq&EmGc z>9wrR1P^M-2pEuDt8d^wm2z+ynB4K~aNw*D5uZOwa1v6uAj?hT3AKbU1hcWQLlpNS zZwI;oFy7lO)D{s|S$L~E!f$(1=CUAqVK-g6C&;bc!7*g}BJs88IRiCyw&6`m5!XW2 z5=#0hw;k5U(%}JuNWeGu0Akou6ObL8-b`4K<64Wqb1$}rlet(5fu}*;3adUTOGY8B z{vKV@i(|Y^T-L^+g6Gd$=T`*O)9gNZ#+L=N>p(I^Zsj$1;pm~JF#nU6_9U_-EE*CB zslI>Hes*%vlV>a2i~<#pA;qU$rM^)XhtIWB`Fb;n-&g*ZH_EUy+FWM zj&@2WG!AFQ-qZ@-(Cz_VZ?5$nkRJWavO20q`9C{F>)cJ6qHZh#oKIRT{S^TCu3R=` zTF@4Y8_iMtSNI=>YQXsXAYMkbUDK4SDO;llEiyU`uwz?*7i{b-i$5cZ%T8Osa_Kp$ z)nE|p!p%eJem*m1h+m+?)@w)t!rFR-y5dlbn{lZ#)m~ul9jnQ(QsbQ=dTL`}+o-fNg3su|>9{4AVIv~>f63Sa%$S%VEDbetua zc(&m&u87w17D4j|LXBK-d?pK zf;p-}Eeb|72(cN%9U!qtjf6tl2z+#CTjze0H2Jm*?|)OQJKPpt#OmZI0T5IY0Sd?2 z*r6JMnFw4m#XUM6E0cqDv`e8+gXJ~%FttN?EZtXl4=@X2z9}ol-EbPjZ4ZRmqbf03 z0AGmO!t0Tf*NA=1_{|66J1~WPpT!^y-@q-s@VjG zGXZ#p)Skv(joix1mz7&STrtwkoWJF&_@J)n8VJ~9cQ=T`ttn7*(F@I$eoNgb+cR`9 zH$)M26Br;+5qfl8J1K<#H=82gnt(dtYfd}-*l0g~7Dm_BAwiuFI~$}P9_Rtoh)K4S z52ldXMh2dmQbAS&fLF%l<-1Z#3`eAzz&8maO&Dw?RPS13S~0~UI+#pt#K`V=~=q19Z^Y zZSc1Lg-5|5CFv*`xc;W_ItGF`7=8}H@Z_r*`s0DE{P3wNjdK@D1GmRCz%w5V2E1h< zc(gC`V$&RizlxN}D&Ht>Pj^ntdacNBP>v~%ynf(bngN|F2FWm{ zg_^7|V%o{E<{sO0>%m5l0}*i?eDg1gW}eq(IzY7fBnW-0Ls{0I>;s$|Fe1WC+oC6I zi8UbVup8@wnQ-U>_7nG=@_|IcLbp%K!TzL%_lrfzGYy@bq2c^yWOhj zW9Eyf2{Ih?vbu=ScV(6-b@+svl!XTXb)a-l#Or9r-tLUTxvAk^;iB6Q{G<8*q6epH z=RDJSNlmZ2vkJI#^;K!wdt_(e;*-c1bKOCSsgk|zS2#vs8mVBPq~^q3#`y$$GwsN& zRs{LZh&Pom+I=wN*_e!Hy;bp0Nmr^p>(iCDo?p&pWL=Z4%WlOcT8g=pa8_GG1Ky!S z2t&ZSOhDv~&PsVDFU+Y0zl4HU!<`c2Sp8l$8>M}bM1a4Y9*Z$#gIfK#KlmfzU|DCD zauA=8sLgDOTk_r0mw5ItLVk)eDX>Xf=n|uLPnBW9Yvc4OjEhJogC(PQ2GjVe)!1OM zF>1&vWiS%x#O?rR?8yN&An@lGT3&^Z(`o>n)nu0N?5WLOUx@I!XNQ1fM%2$lbDRBuvN6q^{wNV8Ey(SOu3^1Z0%vF#n0dpFnJx-k4=FA%o*$~Q{L`aYDm?7jZR#@nBeY*e6J#$Pz$`dkP?0j|LTnM3sIjKg$uh|i zL@q}?`TX|PwREshO$u5Eq~;gdavAskBy+{^K-g;70;RGnu%DUEVjHuMmTU2yr>4zB zw)7j8EafZ&TSFLui@J0kQHaEg$q1`ZeCFo$k;pE7N-&ZukBg+o%z(&JGpm_NAHx9x zD}#Rl8RiuU*wux^+iU4=(+MzM;1*HhAJq@2zlcA~#4OxMKx*gS>vA9fdFx*27xCp@ zCuq5mHU-3S9*BgBZn-?Ln<>j#`yu5m3! zM6dd=o>yCd#We+%!J*blApw4xwl53S#o!J29q?bP)v9%_Xx6<+HH!-1z*_ z(ZIV$6ian4t^E&`0r$|bTvy(45PZg9CL1x^$dOo}-#Ozu zaK)*XgSXO+^Jx$O@L2j^=}CR32bMSo6eVpN2adt;6mv7#VMI`75J4^XENb~@;J9ed z5>*TQKJe@a0g_ovQzT*0+;xVEI>49O5T~%is3t`6V*s=1Gv$lK0c>Q9F)IRBA)fm! zBgo)9Q`vM69YUN~cv|kEXxd$eRX>+IY|jA5LD<2-6}7f}E&IU@KZ%FqjB6nxs)ZOX zp0k$i?^zOIbwo6rj=4HwI2qdN2y=lx0cbZ%e(m=Wv^$(mr8)vBm4h`TzU{B^FAU_B zuLDPUMf)LbOy_!hFs~-H4+$8jTrA-mz)ka4=o2-qzActLltdr7uQ6FP!Tjr6Ziie+ zie=G|^l8{VTnrvjg&E!w3!t2NAa`WHK@-Br8Ce}OVBv{-mXMI+GoH{~2{`;=y6t&` z))~C)8PE4YMc4}!`^ljc&uu|kiG{tnlWm^jbah5L(s8P{T~ z*iXL!lM;m&PR)Hvsao`|dN5>QV7VU(O(ZXy)`ZYVd8Y4w z&9-uW-Bp{QNnftTGZkCftH_8rlscb$@I}STjD{2EW=1@-e+BCO@|r?>LqD%C5~2(7 z-T&+B>G%bGxrHjoVT%to0SVwG>gFwc27TS!fK+@H!rWu3tQ>JMSMNqs&!KUcO< zUluFlu)r~GgOD9{u|7k0k)YDuJ#9kFMk{vLDqrW<2pRTtivyleTvCZthe~951BX4^ zGfYSlCBGEHNFsoCVq3;XBA*COij^!>ekd1AgKJx@3x&UT8z;s-bM_$h>5%6fZVYA{ zOaJA5wKYdR-$70;j2$(;bJ>Ooe+0>z-5Se-J^yS^$b1*Y^5GannKu~5TcUOx3DS>8 zGQA9$>{>L%-LnDF$y!n1VaJkvG;$cy8{1{Q5*k*15E^>|2~dhOyG5PA%!M1x>^5~%Ef=*2QXLAl zcF%rqYe|*|GpS*vsO#MA3g1qxLEQ-`ol;)f)=f_RQHO8(7r;FfMSRYX=+Tj1^%2&+ z;4OlNq0M#$(PI`JF+~xfMn)ebGJG5o|Jd)0Ljs4?9|f-SfLw?;DiT*v;%Mr!Oxh;j zUPKMbq{Yrb-+}CXBLFkic9cOfd|rwl1`J-*3gZQ4J1fD_O!M3XOh#rHV(Y&sO%CJZ zQDX>`d9kl}zR7oWqZ*DD3$m28ilG_S$jLh3(grP!?26GrsI+?%50xG~&KWjB+`30e z3m1RSK%4?zcp`ZMg)vwNtxT##fW?9=j`}mGrCa>gV5DVU-=vHK20&$#U%KO9u>oN3 zRgM2b@5Jr8?wmjyMJ=2my5KnQaEaXfqp3;Q5YP+#0>z8@dqnZMj`-k z)`v=a=iJqRCw2$dRSA{+n;Ht=Kz!ne*o6y%5+kY%;Ka3SG(CZC14KIsNOH~d%~9;W z+&pXqPMi&fEvD*BVy_=;b{}TA_IQv`ZiO4r>=3cqM>;>73XmsC{&%79qjP{oRNDql z-e$vPJJ)W}+~*H9Wp4RD+=uv=6eirA^gjJ*xmke3MbRwyn~>rLs+c3>p>MD=T&FhG z9C{ogT-EZ<^czBrlI>=GgyaYq*``h#uqrwicVJ5Wo;iA0&@!o30*k8Lp;$ASyxWsx zwLjU;pJ>e#mj#))g0I5?NAV7m=|g7xxh;B%onC-<0MtJgfaa#(MKU$~p$TU1Dfi>d zn?@pui~th20vt};dHOH@ci)}A#0sdT3hfz?C4YT!Vt#N=`{}>auOtBSic)cOCxW)n z)Y>679%)uqJ4&Np9gX56&#IWfZJyBY1 zILhpmYFa>|x9si_sL{)s3?Ve=?r{-ya&)3)o{Q!f9P zesU~bhWGh~%g022Nm3Dx%t{ zzoRwe=$H36kAQ`g0>Gb>N}sbVxQG_*++f&L)yRieM`M8q(I8=Dr+WmhLDY0_cq0Af z4*aotzXH&X&r4QbCG9j0J2Cs&26H~X5E46rBV0%?l*e}(=z?Hz^8nM9WM*xVJ&A=t zB31$jV(*|*XSEg`5uncE#YVD;r-rhO@OjL#&eGDLCzA6TqfHMN*o~xl0wN2$kd7Wy zzjG&zk*dC9&K+P)@a7&;63M`t1H?Zff%QbFy<@i?6q5&UM#Z}ns2Lg~fsE3i4u~?d z*u%E!o#&DeWfjiYEtWi&Hy|18$t$>QoO%|*1AFA<_rmmN!cUPKH%RRsSb?ptIF61sctp#G$l(io38r4e*iS2qO! zFzy{-fVBirGs$H1r$LItT$q^@huj8OSe$pLBv9|Fe1TcdTV>JVq{iOk6~Dj8WB=;#|L5Q({>xqtOfIj&%aPOwBsV%>i-&c-V)TIT4-EnGt-u>?-6qJXv7*gh zH!DTLr6DVz()DbRnfD27S7X~|`wF^e(H?pTY(KAd5Z?{CUVTXl1~aAKE5YU;)fGw)jAGT6`G_U_fBrSj-3o zf?t45u_1aZ#EqIzhmoO21I}~E6J)^-qc`{`;)S zx9(Jbe)82NU&I4q6)vqp~>1Z7%gN%0W#3 z63==4AgUy9BFeS2de6Thg*h1ch}|t@k3k29RQwmoYsP+XHxjTikS+I+5>o>jbPxDQ zFue&Y1>uKO3?p_MeOaHlOavDhw>E6q;@cSb=Ej-LZoa4LuAm7piBEv24Z##V5fs6a z7_v5Cab(gQA#H;SXGsDEbh*NzvtLzE)Y zV~#SuVmcKbg+U5; zVaXMh*f{K8m0P7CyAjqfjtk)$>}p*UcPF>2qMa&cE2mtQsB4Q4uVvMmX#?qf*wVJ{ z_*Mz&Y7Sm!ws|C5Riv4tG!}8uSsh{nl&T zZ)I5Bds3#~CfT^^0jJ6=KB1YymcXY7WmlfYZ#23mQ-;|S&8&!J7NIe3!+w#*{W79y z9nI7_Vg!cge_^BOCZuV!IyUU3gZHU|@U!SE^74tM82o{cwS8uX-mz%+Dzpj%%>}J{ zlFbe&8seIwnbEkf=jkA907b{R5qR*E5V?J&Z;aT?0Y6{7<^@1XR{}p>be0h~FA_P< z`7o`7@P4DGFZ*EO0Wm;nN*!ERPBln@n+h-JF*Qbzq%oL6v5fH%T2Jz)cx@r z!YRliC3EROU$AA#5rnF<8oF$R>(TAH0T2g@)lJl-n6oSei^<9l7a^L8+{UEgG9+u} zw+&ygrx^6d^onYFf2f+`X&BAT5o$A@X1Wi;wjO&K$YAor-m==cEfQtyP?tq~8q^6x zyaYxZPe~MkLgx%`=S@*!;vlg=BCU0`ESBU>=?wR*c^bN!$r)ov*l@VFT76ZDsLN4D z(7Fw`;1D5iSx}t;d|xD4>Fv|N#raU&TLTO21g*GjcUPcb_ecOOLLA92*0_aU8o3?( z`xaCOds*0HF-v3Vu)3mBgU+ZF&=vntcm=n@8>xCk_|&}s7a-=z0iB$n8Lo4;)n;1) zN&!N79KT2z$$lup1*Nh5(^wrh2tb+I*pL?29UJ-)5Q95aZh7bf8F^$wGt+eE4 z6>h@4+fUoptc?-02EqvBeJHV_ltMFS9PcFD)Zw@@Ru;A0YuWuYIfs>0Q$u;!-UK6C zqFi^vc=4|?yM6k^D|$*td5$|Nw&V>XjG|c3lZLY~9jAy+{a?%Hj7$bLkXh2f>RvDCM_oH5kCl z_(g2KR3Y>40CA)>V%-zw(n7?e1Q@lK#MZ^3Az~Q{Fb!}&cYEarydJh zQ~ar`lR&qm+PWnL>Rqq}TA4HgNn!+p@e4;iE_@AJCLJ&&J-cKtxgAvCc2yGC_|PNE zsw4xlWFG{Mi#z9mQD%&s2Y~@>SUe4~;uuE+jS$>mW1q{4vk8yc{N~CsIglqxH30?ic+9rw%R1* z!nk4;ceWn{DDq=iZ(-sCH(Y1mFa<*ICI1-xjsoEUVYM=+toZ2Aa$ZXMF+Mvq}ahr`F1b6xuZ**QmK=Wq;qIv|3~ zs7=5I!ZAv=;lEc`?wl=_@J%L%iCz!Q^Jk*gezR*9EKIi!n0GSY zkSpfD0fvRd+2f?Zd*wdexb6KYrvKd*^!FNX>F)MlhM(+5tZg7t8!6ZI)v?tICY(hS z1CPdGo$#ZYnW%81VMCR`b#~mU}%KwM`MOa8lT133ta=n{o_tt z*FPjec~#H(f75?~A-byRf75^AZb|-yel#-}_5X(~q3H2n@dBBqxK zcwwIQ36epIn@ zwYzW@+3GF8h}Lum55WUk>H{~xOJ@@NqgznTETGUB2q(_ZJ%r5_tz{*SDaF!bULa@| zwx5M=+#^w-8P%$>mLF^}B|Zo#dpIFYZYTPrz>iT?02!^^6e{qjbn9}rarVoiARE`6 zkC4sBFCzy>&$B6_`0~0k#G$R)c}k&~4qGnfVR>AX2v+QZQobx4*mTkBhgJ~vD{|da zb`>46Fe#Jb)+#wSdYv4)*A=3)R6!-`$)+*Ei zJbo3!uQfF8>_)Jr2EZ7@h9e{q_+>o#_Ws*AqXf~!@Jc4*{))x3VU8WqJY(!8u$Bu& zoTu&TSY-JYYuR)Zka&vYs$zyw2rtQm)opi_PKU0W`tIV}Z+iU! zQKWvdWsAQ-uQ|^RD0u+VxaWWTV-*_c`w1>O^AKLVf_XDlOT4wPTF;jj1Bw#%dexzk{T(bW0TX%nVcctTLZu!Q^y0U)!eXfA{OXvq`?i2IA zAnp+V3m#DTizm6#o_mQYMc<@eP?W}Epko1arJs^6o+#Hl?7Y(!N{%z1V*A=lu9^IL zwDmmpf^Mqb2Zv0B@&`P|Ya^!K_cqUv?8b%IA~k4O;5n@pq2&w}gYbP>&)p#BYgolx zNq1gh5dkcbP2tJ5$vPjB$2ez<1FqLwOI=VrNZHe6<@RY*Z*rEwhJ~mxvKHTz*Eevo z7dhsr3Vz_F0D^YwT@A2_Bck&j^?5hGyO5Rax%_^D4nig~K3IX{dJAiMkh_ylAcnSv9uUY{}R zRkSr3kB4dhbV#^-{msA^Mrm}XY5(+yv-$ZY78_s*6?0Jl_0NJ2NY-Xeash!rk?5kO zY;`5DMK|w}{n2`r~*7@uCQP;eT9%mCOr#8vj-TIZ%CsS!0G zgzZTL@+AQ|xB`TJ^g2Q9NlCp0eKH-JK52t<+2r*|Q=$Mz1F8VBu`Z=)Pk9JD8G0yl47awLXJcDM+GFRsfE~fZ7<_vmUs=emx+6oKQbgZ+&`jSTZan4 z?>oQ#6XjjwHz;G=8xXh74Zd*3@r#C%Duof8xy2Fr@Q;P#sYI#i{JgL1U0B{9) z%smye@V`D(QjFUlqqTdj^1Fr-{jO)(BFUfIez6@X8o63E<q2f-0C$u#QL$1ik=hRB!3u zOE1s|epEHbw?ckk-1md{i*oJ~`y@S^z6&?%PttLCOMFyhF3=}>7?6?R!}_ySna|IG zI|J6)Ax2PssQd;2H|~5L2e*&-9sL#hL=V2sS5z+>4+i~oBKZIB;m-tfS?s8^${h&` zz~cwYFHk1EpALt??d8G#3Vosn3w9kJJshOWV-zKC3e0$Vt4?%qAF!N{#W}bI@9o6F_C``w?MAQCuzY|MUNki(vc+W;H-J;u5h1!BTtg=U}SP5ad^&+wM+gZ#M_M0 z)FG4M3E$jbpigcb;P%MXj}Ms4(oD;u z;h?`k(+X7g=qd6AbYw0Ps)mA%dbJTfFJ#&dYODMfjj)+%IvWR#km>KQ&?m0j&S?i3 z%=)RQ<^H%{0@;hZv~ym)G>*T3D&}y57qjZV258p zoiZJ+{1!Flvvh(}&Oe7+AXnrQw*YKBYC?aQYLfWO^}bu{XgVLejUAQP;lRbX1wU7Q zfS8inT|beYVtWyPy1k>izf*d0+wIQi(1 zqub{`_xgR;t?n?QAJKRC4GaCE`~kl`I+gCGB=e@KmikTn7lhc|_p(#_J?CTUx4_@T zuM9GMu>Sf4VJiAv_!oV7IHWJ*Z2XZ^ptKr%)|~??SfG!JTHM$WugN%`HlWF5W7yVs z1DrW#Ivr`wL}t>#TwRm^S=<$nJVEt3(;Gqo4}@H$TFy5v6b@_}b*pnvy8z-HP2 zbVd)Ijdc2F<5n5Ep2c1wdz=|oqCxW1S-1lwc^GhU;(*NBe&)^Ee`nqmwP`;Y%e$Xu zMkUCuUK9zUnOe%i4TPZ*+Il$nB%%G^=Rvjof~dd8DS_Zcy^PZd`x5$HzKg%YpWI!<63hCh z`Y3ks~Dscw>5o^5;&sDE2tlB8b<7s zT(6K#7r#n=_Vun;igEM3fz|s!Kjm~5is|H7QCik~o#;tGjU+EXl_Orj>;qLgAxq`nOoKlz5 z`Sx}#iCTcLTv6@CAk&)@*PD%}8QzdB<6;*mprVIdo0PKVW8qDB#>q(q0Zz>oODAB#79Cin_nDHTq!cSg_#(c{ik#=HNb}{I9rB3h6O+OR~RY1LEw7>;ZRPx~w+g zP`~*_U)lXgAieae13Z#D7X=!jtnFSa-gfJ!@jii|=#w=D#yRfPUpTZ&Y0UMq#=J2Cd58Vk z{;-;$w;t=+9)&#eisWdBKWc0y#jGy4k%fj`4K>c;bEiXyhEn zQwl7NoQvwbNq;)pYy6S@{Tn0?RMD;MB3u;6dNBH9WDs%Z@?dNm z1h2MAKZ_LhGwLQNeyIaXGZrij0DhV5E92h5xo$MiYqAqb8j zN{01i;f=mv)21WpvP5-ZyGqp*!iRbNkHyxV@E;$Vn~Fh;pXW;=s>5nY5mgY*+eup> z(j9q9Ga*c+0oSNqVkhp1Bf+8Bgojtl(2YT~!RB-lKesnS_6 z28N)+$_`#Y$(FE0=nZ2Di#+6MP!PCRt8-6DYbc|s04FNtb&z`*jFQh=QL4pqC`%jE zt)5;9(c&w2u$1*p&)o&4o-3VGTa9yLO=Yi+pv>?khMiwLyC(2;d7>l=3k8`ljHEZ9BLerJ)dwcVEI zo1%Af#D@rE{-g>YkMVRmnt_@sB&f9}rY?+bDDbFUM8c#Z=7+ov z91;Hs)YooO|HVFqBtfA9x$h2ldDKO848;igKq$sm-CoODfiw9c5s;IYgO&RW*#U|} z{fJXg#9yPI{2p)=TXA^?&$$U!TxRC%cmiDu%X0hhBvAk0^cr|Y)Q9BH2aKd!&Hy5Q z*|`{8-k(i}qD4p5ErLhZw#8E1>`ix-yi>;)6z-^?8*U;S71eyOIvcGs*Qv$aFy+>k zD-DeD5p8Iq8QLFPUYoCFQ`I~_hlB=}6oxVqWWEhpgC)^N=>n6PLs12R{B8@Q-z1~6 zPbOiip#~i!DWt`~Oe=yiLY?kga-LBdQH1jZlBAIG>Pq+|`0iFkbBkmZFJ2yh5?+V* zu*ZFPeI750Wywx|yDs1D=M3(1L-9cI2KuK291z=E)JC50M`r};@Oo~0dfnn|mo1v10g=@VqEIG8Xm=7G1_{6M z7EKqCKte~QxKhoxT1rkH8_3;(uMEM z1OcRxj@#0RK_d*nivmU$SnDKF7O1<%)(uX(1Ur~+L^-9SR|`^)@Lt3~n7uUkL! zi~+*)#B%MIuFQ=*zO4DY3OY$`|MvRh4dr&;AvoN%+ z_91n49&y)rNz#46;Zf(F7^%>ma|NKpX-@}+oZ@5C+ol`Qvo*g_{3A?%CcdS}ogC^M z{qePO7)BXK=r_ViVhGa?tp-!`E4xdyzrE;t2}7~LdLFlC24#;82DO;qthtq7O-f~| z75?POpJ7QE$&4F;bxbJ&Y5`G%Zw(!|_ZJuvJ?bAi z?U15SwPjn#0B8uo_*grG0os1mbWReqgg9!wTYIu3DwcM}6l?>GLR|)$tVj{c(}Q(Y zvDk_9X0ma6eFTaMy|(frn-k;MCK^bmg{kshl1U*d5H0Feuz&(-dsIX2CzU;kA$OeFYK+g?(gZ5p+d^5@e> z9O+q?Bb|YX`{!YpNZLa;o3^yKXB_(syKfI^+RrrM**`TJ6p^`*X(qIrd)`|Q(4c{2YsO3v0rBl406 z;3aWAuQ&;?88_i(88>67DOY)zq;vh1p(I#cPvrHA8Zw+JE_A;q@FG{Tpw+vbpDbZ2 zXlJuD@j^7_KD#Bm=nQz zZ+WU-7|&9f3fKSoubdQTR~NvAuprwHVrVRV53}8UMv3a}Byp}6=o3F^y(7(&=|JG4 z_^bmjB;Ue}_<&)ddP8|5e}z8Lqi|?A#Xb_i=-#kK{^G%5r90_}W~U>@iR$yXCH@M3 zawF>IE~VK|CjuQMUMY75A)g+Df$=hW%eTjp`fN||J~yC0VVI~sMzj2UCE`!i74A9t zmu$pnftkmU{_EMV&g8sstM1dg`0Q6_e}Wn14Vkb3+)}v#h6-kB7WpRmhQI~=hHplx z-7)AZeDw2+k0)=#zi&hUNl*8U$7PuWvv8>R$eXOa;Bx zB3y8%o%`m=`Nv-$>m7lmN7*Q2=%{amK>qa#eWK>6S}3(}G$Q1vYvISvtI5@OABy@}oorVce0;A`TIqvbMhdvLni^N9qk>+QaE4b{d?`Y}VtEY*cP}3C|%q zMdz?zLqiC`Kn`F0Mv;XB9C~!5_7f7y}&AyOdQ!HU4@xTUX3CItNVupw>xNX!q zQA=O!Mm+>bF%o{p&A}={c6HCS-LF;f^}s&Op+4|d#Ad0j{Kjq1C@YY!z`t-t?Gb;} z0lA{^Qbrx(hI3V7lLsvs}s~{!lc(P)LJU8^%v*WvZ|bkG1PRZ%bq)gv1G?lmZ}f@ud(w8EDG6 z1&P4cmKYvdkzb0xfAQiQ%Uw{H>R;lNG$lVcloA@*trx}C>c6&BuR^&AC9SJS-+*bK zU|SJ(3GzAnJYUK0%#7a|k>7dR>38;>4fAL7J5@f?Kz0#uGZ(;(PQPj!_~+q->-0sV zJzq5b{k|vyTnxso%Oy=Z5ST4*GT2H+)jF>eTTTOg z0sR0!YI&l`m8^Z^l1BQR_%WB1SEzMM)h61H&+fPA#f#n{XEpkL&g$(YJLBG21vaui zvXPCVYs->h~q7KhCe$=yNP?~XT&CvW#P@4YO zI<%30%t42i%!>PZT}F2s-Gzb5zf$=eSf%oO+?o~w5yk@pN^+#W}rjmRS#|^xzzuzNmiZ83HJ%?0%IsO|G4Mc#&3@#o6H38nveNo8@q6FMm+&=W6?;ZE)+uk*N%x#SVw{^FhZvu}MXMx2= z{`~Wck1h8U@A9|0qkpZ|g&!&QF+HZI4870uWL3Z~LX9&ZI&J0A5y}%KZ%Rn1QktX3 zzTp&I=_4O!-{(?@lAE0EU&SU6p{Zp}3HbIyEUf53L`vsa7wZL1?QZ7LReoE51V~x; z*nyn(y^3i>oO9v9>_hsEI{RELu?7oW-87tC#$vW%Dp ze|9P{BalNAUvO&X!QSMG4C!n*5n9b`OJUZiR|%LIT{#G_I_k2t_vduli_R#a6p)#; zjJ<%D*F!8(x(tprIASlN`U+T{jHNC|p+n)mMLQp%>H%SzLQ zh9Td&zGMb{oN_?-3Dp!b3~Pq@%WA;NkXrEyN}lXFlK1DDj-cB#eJ-b5$LIXrc$$t= zBndKe&sqB4oxfzxXGjE3X{LV?)@P{OR>9*%K|8C5T6FVZN8!Hu*Z{A9i}y0v(#eC3 zhBF$-bKTi5Ap^xnR_EO=MUI7AzahoG8@W>1>PthvWt^s!kB z@vFyWtf~dt$;HAe2UQ4S%T;?E?@4m&P^zFC#^dZk{X^_Q#2t84G7R#nl)6=|O;g^W zRFOfH+P7(af(V2hN0)@UXW3ekKs{}*rl7@S48tT5P9l0|pbeqUv~a3uG#>81f8a_5 zOjz!wfbufYkkkiAdwYQLga-pBi&Ah3CbFJaTJEJ9)kiT3JB}t}S+US?H{*eQ=~|*O z73o7Cb%~lW4qbWPETuj3Owl;4Nt`XveVTW&7-%Ei(mbx4hh@R7RKp26?1*+CU!P_g zq7EuHCo-IXy^dH-*!@h7fD+rGBIbuGzNzZw*rsS;h;4y1;P3mq1GfqVqrGZ3!+GYp zME4tLYwRNBj1&t1k|}Iij`wzrmOvqF!`?$NY~n>k?dJ!<^-*?F zDG;bqBWY0=K z#mL)*u^p&zTv#0Q6?j5$*j{g|-3CJ4f>09*+Tkfv(1O!wFydKPX=`c}O?5&bu|j}q zk^pl^?Ie{|a$5L^va{bga6BER7DnSQ(5Dv9!)&VPrgvVrQ^}G9(IQ{N*wj?Q!+J-F zhshQG%o=xb;c$gncK#5B0QhRoyweh6vD zGSOxW0-hQ-8wbpnW}{%Dh;evhiErrz`h*l6R~3)xXrfRh8dHn~ZZPj5!L5nnlpqK- z8V5I%_wrZhQ%EV6K@~N>+XVtoaq-b+mia66 z$-R5+c@q1c?(W@JRBxp(LCvMrcycL0gfxj%v@pH_$0`Y6X+xvIcwidpG3p(s1)A@o{2}i-)!x9|ym4pb zHk~TIt-A~Jwb+)2&Rnlj%r8=7!5fwvSp|C0!Xy_Q=04?52eTQ!?T+TgqQbMX;zP0x zLfDcvhPd9oN<1jj!t^yuTg}U@J4r}ip$5y5O#4H0B508dlgN^nkhf%@Q+bxOs71J^ zt6c*XPEd}8RWv;7;_f*G)H~2y4Jnrf+Per+cP8SDOhgW?4u>>7JP!pJDLY_bp@gyp zo(uIg!(ONoheSWeeO=$DBX>Aq@feEV2oViM4E?QRE+Z4MBN4D5zXfJG6>iI$`d}!} z*7x>id&2L-=}5aON}fSLs@y(5d4?TUJcrx;&;If3f9=)apm$S{6aK}Gf=X_p^(rhP za>E0vxAGW5drYJy6!E_<5A(UNna@2bmQ_IRa-YiAI^PHV{>*LeRw@&aA7?A3{PMl! zPqV0P<^X6wm%m}f!T_1@FskFu5StgW*Z3nI7_iB%nHxiBprB8Fu1z9C*fI1ANNq7f z2nWP`{0;eGdQCs-NuANN+#xz1jl-NYY}xuO{Q?GWCh1_%z8^nJuSN1vpEaOoxs!7= z2#lVGSP^s-|JhxFNF*5SV$S+sVO(a0&X#G5Z-BYRAAQdbsRizY9*WQUQj(wgS0whY zO_Fzf+D}g@UubSgkMq~`qrNZUlgFn6Gi$+5jVX&Kee1u#v7FhYeLsGdUW??TK8qN( z$Nf>NRqfxCVN1`@3lg;%weQ2v&};fppE03lxMTfP=SslLEDzIfaKL3UXy1?@rq?3* zs1KXc!v<5NjbW(!VJnTl7|}C_({xO8z}%OgX|C}{edY|I{Ns@iX;8@K2bm*s={)gZ zN5E>`^%x8240w-@&`I4h(m~8RM0!1L)0i;}h}{P{!etARVxNCIu#E>7HG`{OwI0-9`HY=^s_i^EBu{S56pB7tMTa_#f21(>Yf#?W)k~{~nH)8mLZyN% zEVvAhITNc4nju1dDr$&r2Kv{TaFPT}ZnKSzbm@|W^ z35-PyHVcN6g38d{Vza6WU9upWFjNW>0w64;UG0`lxdDO(Urv{rOkCIwC)!=gBz?94zU=agyTrTI#~;t%{t8>|Ani+Su;jdH z#GNZL-RH5rew}mvZ z>Io&lgs=m>`+{^trXo*#S8l5{idv%L4P;DS13F8MK%YjSR+RNq6AFJOz4!co{>L-d z;afmTK0NZ9D947Gt+a1$YVwni>4Y5T4OFN? z$$qXXq-%`AUPQ>WG9JuO&kjdk(nHRhB}Ne?b6TUgfEj*tym(r@ZOn7-Sv!O~teVSu zk@o|50$0atI*0xBc`4LzFN;jFDWB$_6X&BF_kirB~&$ z1aV+thXn@}<1In^tcD@bR^k&M_>$WOML!c^1o>j&8d|elSq20d2f%Xu-tjPg>vgf; z_M&0@1CjUCl36lCY;@E9wgGngdFQ}NHFp$_?BJBQlh*RENk$!BCR*dc2~jh=$b}3k zVEW+z0;!iN_No0u455i|IzQ9xXus_+U$EXGASG5Lbqoi39KfjLsnxMp_!qVnh@8DSHtWOphcDfC?KNO~NZ2F{cI{MQ)-g zYb=yXaKn$ zSrynN#2|yve4nLuyRYo1CSG>MjGh&zJ4F$JVm}lR4RLLUrlQP>Bi?5hNO{u`jw~mz zBaPJTRL@nLt0I9{H_AkmqncuHfRFU}Zel&0FuV4bKyUO&&U8;56<1p@$w{K&6pwV* z4ZB*>zieh7!!eG;Bl8LcLg2XHV$n#z5=gZs7>km*sk4osl*&1#xozL^7(tUbx^!3^ z#8{O=qDAqb;4-oXNKI_Fb_T(J?u<1=@K!QoNaoS)T7mtDR3xjiVJ{^f4y3BT;}qXr z@}3-Js*KDQpwSFxZDQi}ohWY}$P)A-L@{I3pl$%&cO&hG)2&QI#9Shy883Y%IZ>-E!eA zKo3RUikV_a^qcC)vaE|i$#vip053uPY^_L)#wAj~`*rsG5`u=s`2_Z_DbXC-H&bTm$!M;gBjNL*fXW_y^; zQV=$o04E&Y6F$6r7iax+Fo_Z&Fa*1vFjk-)PxE-PH^okzs8+FG8LwM6{EzRy!+S>lo*lOwp90@ZHckgKtWSS?A*HGX3+@Z z^zq)^UVpN81LEy0`5yKCV)_q(frc>hP{I-=4{zl#2hU>qmV1k-z+mC(g zCw%*{-2UYCFrMxmLs8O4lW2k>d|7e^5=?!!b0q6#UtI8uzS$$9;F0IG2m|cZ}}!)Ll6x=hy?ei{c zrU~tR1*R*aXF7!Sz-mN&d*q`B>|<^l9*A;e$SebJES3_9UsF!_4fzeJbsChowR-(aEaJ|z+(#XhuhE@r_M$aJl#v< zcPkU*?feg+bSgt7OJPhAem!v2Phx3EQ=k*5aEzpZ@GbEiJ)Hj@*+Zh zg(-w%)71wGox>RrEQM?u;%~F)d#Y0r*TzL!<$LO#Wl$^P*{MsW#&M^6< z4+O!d(1dzcRnrf+o{kFAon*G~73;eGSn!2=+j4-EqYzYo~)3 zq+x~jBC@ok`!h^eO;=tErmE6}Y&J_2aiO*nMy_jzC{2M3myrggK6^WPM`2g@hAYlD zvv?+uaI+E);u_-$llDUO{#N%`-cYKw^HA|Mm>!iYNBMAqnj5YtwOJC{Xj3iuzzp!& zg4urDv?-`+l-pDQW3xQ*Dm)#$B0?5Vqdjx#*>v!{e>!oK2Saci$LROWdVl(}JNyF3 zi~w}rhrlTSy-DI|v%6fDb6|#@L+GjuYMXOZe_J;fk=x5?#iQ{$zsWb?97Apg!*X== zvPiKrL*?}4s<;3?Ej3}N?sE@}vcf=&?4q6#7XltBJR{<;Tjo1qILNdUvY->rT_;#5 z&#|nV5;R#o294go-e*Cj-?@z*w#!1a3XpprE!tZUMIAx;B`}~PB*L|QQ*2?QkAZoc z6<~Wx7jGLr&Uo%4HpsU8ooo45kwN@A=lmW6_fGy@q`#TYEtX$}l-so4`87cgjrw@v z-^UUk^||vf>58MuqaSA^ZnMT<5XO02KVk|1D1@6zd1kPR68mgA)^UueKSrlR9mwI{ zKvD#$#g!WA+YimV;{b-=Kk`%^+Y%cv>W|Hl5gFv%_KJ~np4AN5w+j!pthTp!E^%I; z>CYpR^#-DyC01k5?$YzYelC%UKT|t0a3~%&rPQEI8FitM5F#fQawm8>mBB(Y$B@VP zIu6~p7sXvDPXag4Bx)yT84MV`EhR?jZQDd<{PHxMBeH_b>>f!r6M=5~7Jb*KUEwK*FPuY89`|?}<$jc+zzP{`2 z>$pToi?r`Z*P2^mn_c7ojtf>L3Wc(wQ4@kYmuCCop`ldVsC}C0dBcL9BTTADF>0&pE|Ud36^O%?VkSN#<^(2FTro4 zDu74umtOvH$M~gpmZk(Vx7-zcN+4n<8&k3s%>iGv!xjO`b{!DhK8-z91EQ*?5tavh zpd!-saiN=l+UGokTHzK-S9VZca-_;vQLQx`7(7Aw1o7ql+H{*avJdw6f%H)VwRVSV zOTF;ixmdhJ$wfAAxDNg7(M?IcaI?U+#U?K)9tKV=nF2MluF6;DRiHj=>R&_*k29eH zDrGUAR#jOmNKkRiYFlX)wx>;WGeEo2+oWCm1g!8yXxSD`2PF85TqR9Wo%%sEs?HO! zg1`teWKCI{@&h7*IsrV1tJr0W+?{=7w^`Mv0~4b)OiiUw4?hWwCi2?-cn(5mSb_t} z?W&Yz9IjM%{LrK*nQ>Lxh_*NB%JHiLzw5$Mbb!yl&{}%MkfyCCIw~x9q-j<@&7HERgfCMKgp{prSB8dJW$qs;;oxAA>tt&72W-MOvtdx$^Bv9 zkRYdnQ;NZ<3lymfL=HU)(H7}-3Klc21MwkTbI~)YG;+jxD){}2$o&Eo!PtpPzQAw9 zsm2C()K_+yLVikg?_1GekhM$V!X1nX4F+_)_4#w!dHVwZSG;9 zXC^`jB$+m~ZvFy&5^4dE_lQX6`_xO}_-A1ENDNOzz3H1|=<-f^MkG?hjP<_v&4^{Y zn7wOjp{Zq=uVk?z8ZlDQVhW+zyRo8_RKOqe8Kjl(uqV*oA3V?^zCG6-uf1E+lN!=X zwM=_pJ1W+q#RaIyJK$4j?aTE1F4dau_d3P#NtQ^ zc&rchx`?8y zW)-r-Mjyp36A#puI+^%nDcU>@gegi<5ceA0fg&sI;wt&~z@lQpVNbP#L$fB2a+b2k zl>1WYfp{#d4y`gXHPn;Zn;Sw1fJ2L!PDCoQnZai-BXqc5i5>v8?O)81hH^Zm!8%W* z{dV!Q-xzd;7emy&WYL{>ybHC>Wa~$Twus7u(ceOxc0k)Ktc%NeqU~B zxs7KswP-2asU3l7kwk~OXWSV=n>ZihkL;e|egFuDlFG{vHU$W$le=CtV77|*4bz7KT2=_e zMj3MmWPO#E5BvQNZEYwwY#9<`HY7L##>Vs@9rpv$so_w#r9gcoGSvNgfj*Hb;nn~X z_m7RF-kxirq*L;>4zrKa5lMAfS0E+~*p&95ir1sNQHpnq?%3i zmi>bSOi_Qx9W?Ehnad3I(rsHBZzdc|rvuS0;5#T+nOvYxk-Yge zQ}>Syt<|-+LDma@z*Q#i5^MkKk=hYykx=459dDlWu@@= zOA?;rB1jRx%O*lth0m~rX?le|@zYDDE6Zl8Rq(+)jsJ{!%lNG+_&;Z@uZ!fv+jFMQ zhY*)fDr=htGm+iXCku(%On9#76SWD=x^N_*vY&@LKpR*hh z3>a2x&9`}d12*YRzP>)*ZD>xKXj$>4n=k3Ev9aDsj2CSQa zTpdt^w^V%uz9vDQ$d`8mdDL!=4l}2?Tz`6*i19!~6Zm8qZ(@gjxQotGd}hx2O;)e=zSU@(-ovaeuUIDNi)cs2Lzs2mFhk`aOEN22FLEC#ljwP zkod2mq6-$CnyHiem*Bu6j{^nJY?(88-)pYAYyf_HYY16|KY|>tjfT9rR2+W*ar#3E zClsVa?!lh=La!uSr8^{Lv;YQsO@WXK9LIY%x*RSm*Gq32@gg6zBv4!Uur3qVjYs-Q1eb$UgR# zf^mb>gOh%qubInDD3FUyj%w-3?$41n7L zDU9A;ah{}xUTF#8Fx&5UANbMVr><`inu*0@$e{tsD&P+Sv);NO^1;Q9;sSA9{=B>LC`% zbmJ^w-sU00=oveFFslyGCPqTzL$Sh@=eZDM4G+4B-;T$JCjH*7U?A=lqhS~|FF+U^ zTGxl=t?*L-6F$IW+){0@orbG4I3#F&PzuW&u@bp_+dQg|!W|d+`?4H@Zr|`WOGK$^9&262AbW$P44eZH zTr$!!PiD@vJodI_$RTw{{kKP>wF9Gs)f4pT+AFf3w6F)bz!t(*S^4Kg-KXH0J1gC* zERCzuAsKWjH7)$)E)mazPwp5ZJf=%HriE+BR)lBCePEAK!%|UfV58-wrwJXO^7s%< zD5JS7HndZ603vpgwy(TAc?K@k^L-N4r?S%mcU(C0bl^}cCYVg&4x~&3C|CrQff%$p zE(gen_a<{0yk2`XijcJUimEnrzQQXiM~fV!l$s5iv)1;JPz#=8sTN3VM`NQ+an0IZWtf{j6>bdypRKPbX8;jQ6c z*czrn67XF|DM|q`*Mf|*Th269!FB*kip?flQvz(hFprq#nn74WnaN|qJ_AGZZ{ zMJIWPsnPK-CPYw%d8S=F!-tu&3mdd6)Su$va|SOX)AD{D;PrvJiDSRIUOGnXh$-z5 zawi=F+LtJeYU%pio(b3-EYU$;#9Z&}?wK(0hF7 z)^gSGFO0a7r$pte{pY4ARJ42&%V5Oc@@3Vwx=x09oGx@lsDUyokQ*0$+AxSAxEPhAPf?8 zwF3Ur`e_ixi4IkI2jt&_lV6(`P(qLnzDSWM>#@soqt*?y^TMqx&>*eA^A(CrS_$YnvHJLg1f$xk)&R#%Fduf8VolnT2UPQ3xJ#$VWv z>?;>&aZij!-@CCnbfEUaBJK7Q{qQnOq+qE`xAN$*02kqX=m4<5*#lJF$e`;SLd0dY zz*Cd5)9kEWVH9P5ce#j&qRJf$tWRknWnf~faTu?PMVTZ2;)|EZpIE>XOqn0w9|e48 z7ri6mA7J`k5Vve&{vu^A^e9K1Vy#(vsN2Z73%8-3N6%3L!$&G|q?ZEoheU2++f%$H zw7oln$dI}z6f+zs3>Y~J9nJn|IE1V)xj@d`KNB;*D_KZ}eWE!-{HK2(mc1X2TY2GO zpYy_xCLoU~P@!q!;Z(B0!%1clXXe6m=+*93Yd#uIO`;f|<6RKwwO8~_Od05R5g8{r zT)MH(f|)BbNx%l8^23>?cUuY1h%afv^IDUfqLz4(piH5-;OIapf&VEdcq9L02HwdP z`P7mThY$_tetnaK$)2uhn|$@+Hb%*DYT=&L_^8i`-^f2xV1SYm=1*-&?orl}5|-xB zwJ;~_HsWet<_h@vEUgml?c`S!?Z(y&IN|Fb&dt&b1J2_@i9Z7hMuVZx8~nP^)(oI$ z${GbB-MY#lw3F|E#G;YuYZJR}w?<{C>)Kef?Wh8x{k)h09*=N>+v5Mg_l12%07q>0 z90+fu?8&yu260RD9F7t$i9kjHn<1(yu#>xwONjRp!*k~EvZg{tw>8fZgsVv{jvfqr zNN`5?mCfXY7Gx0OE8_1z{7mbQcYr|9dYtvShg!wArf;f?=qg5|mtfrc@NFF&v_R=$ zD%tAmNbYZ-0G1P`M&*;@ECU&;P~lS}XCEPdMEFd}5n-D(fs){J@dzUHVU6m}OOHA* zyOL7fQ?F|&pOl<#l)KSS!vwtL=IDMEU=WFMS5|u zFgYwdJm-K3d(;x*qP^X?7^K;`v#@HZ6&BMF^u;LxHZ#+&Xq1hZs(sf;kj|kt!a?Gc z^pd*=12)rcPOq7>G5>6`ldz;EBsi03pjV95<(!<=%zVkk{vmS-YjWk66_aa4KXpZn zkHn{xaP#_sDk-UW+@1$W9)Q7O8fhtpM>=s+c7Hk&*jks)LGi1Uv;-t!b4O!Jzsv>M<Ct?AJ=7uM4AK=p-YHUAT8prrr6*5T-}YOhmen6rC~dKEs`Z3DCwQxZQhig zJwF{tZWq5GJ0*V6$VsQ_({X1Fxw9Z*;1?U&P1;?)x99>QV_Kl`z5Y5lEB7rc&Nhl= zMFvqCzg>fc^=}kMpYN8EC`{N>3I`IKc5+p%o7(e1k&M}LX~s~4qY%^Z3LMVDs=yVX zDl(!=Xj-L?@AKQ@bMfoP9|9+zV{d_UUmkmnY@uQ@B9>uuLjaJERAk*RXO+G&xFdW= z_()DDP+$NiAC=uPp$;Ef;2(0Y2TLnx)RoB!V!oYg{^%@{!hn)fyvgTRzrOzQ!{>8W zn!w0_SD8RyxG-k%bWlhDPS)3Ilr9QMP3Mr7hQ^{z`a`~5#@{)6_u(5;(_1Tm9w=Jf z&ju0Cpa!PT4+$0XcA@7P<0*T>RkKOwb-G(!rp03S^klQc9?=kkNl!R?RAEJ>BchQR9b3gJV$nh& zvIDIM8?nz;_tlNlhQSC@0>ub)1Y%XAoPgk@cbtFlXV05%)x{1Tce2TF%f1+}g$DY; z$am)uRK%9RF~&j~eq`ORj?vMt_g4xcT@;_CnqvGc%j6DG1S*47ET(;eN~S4Kh8QX) zdzU4YShct%-bw0)3yf{mqZls8mEg+|?dmp>b?9UFN&1$>;n zg&l@uQPi8VA=HD7k<;EU0hvZ*u)+$BHmKz@4rjqOti>L6wd~l4#Oj*|c|Eb!#8MlL z#jM5L;nVovC1#p;)igMxDT094DIC6oq_}F=rB_&&?k=rPdR)uviygjBy|P?V`fD^5 zwn^UxC9W3cH82iIv6f9;B|I`Jz)_bPE%fXMAi_eykRaw^;xu}YmMf`gw-welP~d#T z;tF!N;?O|~y~XVkF|R%{8opsOgOVB5Jz`U1_dqurD8F&X^aO8Wq`n1!U|hmqqBn`D zL7-lttsYrKAst=_;l4XP++z7FNA|^zkg)q6mTylZJCyw0pZnOW(eKjp$Pt@m%2Xuw zPYWHBo0NqDTK}IyaCETQ8p8VNDH7ICPa`I*hdETa&3I8DD6#Nl7QMzFPdP1@ z(T}GIdyI?X_=>(c1w9S80&0OCp@lRTP%!d3emzKj{_ytK9(@~FBj^WVZLVAUpZP1V z!3giC;}{Y;@2MRTc$&x`1CJd#ceBy=0QD~-_0q$PVqO5i*{$6{DkT3A^8Ta3&nSDG zV1L$yo*ICU_~(noiD~4PBL@dyJ3v%kuq#N2-Tr+a_DFQr0%z<)4NXUZXVkTcm~BpZ zcKIrdCz422@rGhor}1YBj&JXfM#{ufIh>y}H05hG3ejGX0-iW)8!@hyzVxBM8I?{k z5NDVuahh?ThNN@qkKb0*s;s?L_wL0HY3c`tP;`>DA&x}ob1WMK4^$#b+WV}pIWLI# z9%37O!1DPi2W(T}5E+XdxLQx^PaI}BR$=H++s&p*HT7$lVFz9B;uoUvCT$Naho zrlb_vvSDONZz@yn^W@tkSucqPc)>1G=MF7M`c19X?;r zdkO<#fy$>)1TzQiHTxe4a&=t;fanp4n?}g6mQ>)mV+7)_#kLZrV<8H|UNG{)>m#OH zWR^9q%>q<2XGZ{P+cl$uY9@rpi1@9}AS&8GfKIiA$oCRbk79?mfvJ zfXl@(JPsTa!^6!1fH9wO17u;QVgWqj_Ufm_&(b<-OVkCEy~96RS$c>Z=xP$grB;-logUHP z85b+9poHL>5<~;7V;5ltzDVH?8GLuq-H@GhDy$H?t=7Y7jIT>3Id>ncT~qf4Gm*!v zxkL_@TTtmh@s+)LkCWY@sJbskX?=$=WlG6O#WwqeHgXt9y^Uqk(!z|^y)Tm9e$maD zKrzauE|yoc7p-fN3*0LYdZefYqL)5aFlmRhuw38GYEz&8NcB_T-NPCsCbC(^CG|F_ z!H3^lA+^L4krQ6X7bV+fkhKZugUCk|JMI@Z0u;3x$Dc#2J6Ur$f)Fmjo1~y!@9)%I zSJfJN{9)(MvHHdIbL%lw|E1Nk9mxv#n(SuoIB;_&=bH26nt8gxv$#fp!!+vN=ez2d zI(kfYu&G9d7)!TyZF?GjVE%Thnn50fpooU~5V%|>`6@30C*EPB!&_rT)b#hTEQkPf zPMF+c>$Y{}q7;@*l>1+9J3VevS7DV7$G;y`4Mw;KS*2% zj6RgHB*jfA_uUj*cS_ahdO#%-$!pL?GL!18AqO2d{uHdqUBD9%;C%3R$Ui@g&oQf= z#cv=y=KNtd!;&1MWBA7b(_IX{#&$u3g4HT6zQBdM(ww*l_pF+PCdb1)IiL=r4V&jh zs$i49*oniq_Ho588}~Q}WI~^4z2?Lak!;>sW%(84|S?PMfjj%7~q5#5R zKY(!B89;F3HTd%d5P<(Xj37W+&C~ePZhee(HFxdcb=QW|8t98ihMHPxV7z)PwN%DM zJPnH*(EA4LR{ZBtD-H@-jeh9B%Q9C&zo*?(*W1f~q6}qDY zKAKFho2;9t9*)b7I*M(O@Cc|)y0Rydz{@~-z|D>wJ-5k_)Hr+5z1=M-p?Mg8$bIRltHSU9ZHak zMXFH&`hA%3;_PAUmEiZsn`-nP_n;9B#kD8L#hRqJ*_%G%qQWx`h2$3M1kR#Yo|bS3 zcC*MqnXZnyL;%}eEu@UJxu&#tdkSQYFL`tG0^unDh?BBt8 z*v&nWKRVYKdQlBq>nT%kDDag(23-H>?%KgM(a~yEC_6gg!@i4yS^kDW~kU#=m1a+Va0_N&4)R`K5P z#xq}=z(!(UF!)G+o(KUE7=pqzbvSe)J{j?S1)&M>u$)=U^G6afBn*Y@@Jzjoxn|bs zfxA$m8S0aeFOA>2)d#ed>@I~PDt=9{nC>{=U^a}-CCrD^_3>}jC6hMsGZ6v^ty>h! zvezvpf*36dd%5-t2R_Lw9D#b&@g)Z2QT(#3_1;&aG?L)WBaNc8YWe8?U~x1uy%=DN z(OOGN47a|B_~tZg*bRVN;Mdnhd3|$Pfqo4={Oy|B*CW_EP?69U7%5Zv{bQZd$)zK` zfnLnu0%%fRo94VO-+>YY;NaeGC>x9N8?PA!XYO`#Q z&OG9Bvlh=p$moBR>Eiz919wLAS zT*jrhl=?1rA<}Q~qmY!4OT4(Ve%v+J6)AqXMZ;gS`VcPPS_mfiTqtRms;ttgUU$b(^0BcMJurxd4}|Y>>IFK+KfoG*eohn zt2<_N2!f+$wN}iH2hNJ+OAAf*wIXqjWUE zIW?XP((%kp1bdA?;;2O6z~P;rPEA zk0P}B+)9kW`Oow<9qcs`?xtbfsSkfk!<0D-iM>d=fQVdH&~FcWN5Z|;GRhT6r<3qm zw**Gfo*v8(4+0l^!{;o4i)g{lwdKv(o7@thlOZXX-SAoDbR~gl51gx^|wtzNYg@7C=KOyptQzaak4U&Qhn)#L>p~ zT7{XS84tnT>z(spT))vvU||^Hk11b>0SJ{*-H42;mey!nd_7_E5`OPF%aBiI*!8xO z4-pMpjD7+B3tXTlBu3&~%40LgZkeo$?GvTO!ZOiaO;i*p!cjvq5mcA8&;h3fl`ElQ zPrgLwCsez&LqJN@FR;MW`etC`>I4WFnriPcsu*}nK73J#21}OQRbqKJOqr1}4+Hb( zWqqwofStTku@8D&mEziUMD>2M6JrIL=aAZ~ABsY%lb}a%54a-8CsdKT4q-49LH~mI zbJV$AW}VyRARdhVeEI|9G=5vxJ1%Pk2?ApEI`eUfPdR-kdIRZ03^}VhIH@MVfzH4+ zXiMAi0u@2%LGi}5b~wJ;ZLt)nU?=K}+Yu>skV^I6!3}KePU~MF^Eo4Q=qFfauSB=- z|LqO9y%!Of3hVkFVtn<}*h?Ftx~*G`M;uE5_Z4VFLE`GBnBP)R3rh%`+vz;Q9i+&x z!MroFH0TABI)Sn`2V}v#WM5PC+F&jt{^~UPiDxtFf)gXAQN5~R<;%Kf{a-iTS*JMo zs^K|fF=DJD5~UvIQUpnvY71)`nLVUBEv}RYE4g2%9^i((n`tT&LW7^I&^2ct^!m_d zzgZgzV)JWNIY-?|H-A^FTyhCSZq1Em%*I-f@IvA1g|_APT7UsQFK0IYF-RUGr)~5Ir>#e=6F}(=0rM6;)zvBM{2Ggheqp=rHGSm@Ma#c;C+3og zxAv9NNuJFV?&VJig9PLxEP?zaOtW&|^6r1VMTVIzv5{4^C@LR{W(VOO*nfTepcM;B zj)AM_3{=^AI+JAxzhhEfsUg5u^Y10Ya{zviaxYwU8AS6kNS)Jee5s@jJ2~>T5H+-( zEZ!%emj%Q$sq{^wM|k`)G9X9$nVU;t?_(+Hy!RsFig>RCi@drRr=b<7IJSH(B#W_> z2BQ8ArX&`S=#KBoMl`sR|Bb3tq!#&lrA8KYws|UcYssA>op8-!KLyR=x(q-RA!_oEa(fMVdk1aisbdi{CXr2yZ;^r@T-4A zB$qc0`Ol<8+cHH8XNolQH2yD5-VFVG1$tU|cx2RnAL)WzyTF$5(5UJjsnW~-g@fUw z(!NoIvbfEjUo~p0^YUN!J+M)#arsfpIP&H^>!%w!F4uRhI}>j}(*j6msHMB()?0*>_+$=MAdj0A-D>IX%n4*@%uDBI)JqdukA&!^IKc~SS6lkQn zIp}>}MNJ-}htj|xmu|QN`k07mrRD=LF@Gh5HX@9!D(kl%#jX#CihP85*0Wm85>l-V zl>HXO$Q22hmTgzD1ix-* zT1Q<2ZLuOk*?2^(z(Rbe2$ELgC^J5q9U`{fE*S2~1kmxas&4leC^e|XcN&E!%O!}a zBioh|=`ci@3`D(Gco#(dNsTx$JEJa#$QGR8sr$RSDl$6LPf$D@x5Xz?HA9xP>?-xc zibO_@Gecf98@zU3(UK>sIL+*;3@B&$L{>J0XDBoRZGYZ<5-Se@QYd!`YcmA$rvtMi z;#eQOIMze-TFUGR?%Jt2(>g*cQ8MU^tqh$R_Gbh4LH6UEgHs;i_YQ_r!xFk1D0X*IkqRr_BhNG=7Fq@EFc{7< z`Ru+7)bho$F1XD76`^5k2_Th?2OEA@NSFzYq8y<~)Z}@wMVv|?CtP@doNZ&&0>qtuSWwy>W%00NQX!PZU>oUvf$@{sgQ+^+3P-vFM=?+myb za#+ALIM9UP1_+j%`pgm{bl3d*B0EQ4Ml>eI~ zlASYulk>K1GLa=|vn0S-!fw?4I^Nu94d6qK#2-cqL%BT30R=TH1(nlr*`fXP?BF%OQ(d9YsP%xtq%*8I) z6=LW)4|hi)s;o-~>M4Z0Y#=gZ(+P=8?+m;TvL>YJfYJy!ie7?GhCbZHxDbJ2Yr>9H z)xKg`{JFRy5T*gcV$VN;Q{oAol0f7V9Fk9?s5D_`v=COxrIx|`*Q@7kT zsfA|);Rr7huKcG7N+N4xRg-I(06g85Ot4zsc_d>{$&WNUEME@i^Qu+AF}J)~x$Da` zep5+YL!;o)!6^8KqTmS&q;p6!hgbkI*h4N3D%zri;xsVWtZXnqCaVy58@#6XYmj?F zRoJ~N)$1StgOua;xTkFP%Q8nS?z-KH(s7<^ccV55J?O~GSx}$}Y3pkc>Ts_@_BfT1 zj`yk-+@m=n-kzB(0}|&&?fwIdp(I2IP8UvP*dT;Kp7saIj`#zpkGAC~K5rxlPN-0* z&c!v2)oQQ_azxK0YuFpLcw3RA#qA!A&^xU`MY^JbBuW%4Nyj`z>^Xkwb~;?dkP5t& zujGc;GeTZZS(R=oE=gXKAd%NT#WQWY1jX7~j!Kv4rs{Wckhv-LIuSSDP>i{T+oh~L zNOX93Qx(9yYtZHezG+>qaOfu2-cntVA?WsC?bnFTWpZth{uNB<2Pn&!$D-=P1py4I z{E1|Sf=$L*QiYKU{Q{;SI9BczD~L7VUho<*f$IZk&-!6KH?ei~`Wd?pRS(81%`lzu z7ke-MCXu7L(W-TF={bQFya}qgNabp+1mz)A#+U&Zl5UrGy^yd2n_Pu}s=<5>Np0ch zQK0$uj;GETC+Kw%h)YmwSVF87c4@zpL=js{g&ut2I&rU3tz4JQ-XB-DSDtfJ{&-be z2oC?T*{zGKnpGYtnjrVUplFy6$daA;v-xs;pKq#l_n(bSQzRFzi>7(l`?^U%v_xH~ zyK0H%M#!|%p^LHvSy;4NPAUmbOBTiE7s%thx`-eMOH@TX4kx@=bWC8u)P)a;napj? zyg1QND^mT@QBWkrISqM@Mdje<{K2Me4wj_plfMi5imTqbt zJ-jH}pPVl`{wi$_57uaH6!4rWByPS+%7miV`(llrn+Jj73kSss;n zhWjAWvzISp+jGcIkvsurU|_h;*|3ydqCXZyO#Gt=XxA}Ss6qL9XUxf&jx~$Iy~vlP z^HtZ*yLLZ1cXsv5QZQ226;@6mnYC7>0VPN6aRx=X4S+0EsRN38=LvAGfN>d25;WH$ zdVr^;NU1dO6(mz2zo1|X5jdr=1>-Xp6^YLm7m@FMal!qgq_$r2wivUTHzGERh$P%> z22p!PIC~tqZzy%WMG|NfGk|-r<}8xcJMRx`l`?#Zh~5I0*x4M&6;zV$epxK8(Wo?* z@(br*mkq;jA(}|VZlh`RQ}V@1)?Sy75c*4CPJKzKX7|Erdow=4MMNtR7toPm&T3B< zI)je{2pgWeL=6tJj6L|kJnWE+!zoA>Cs&eIbs3lOHagmLE6 zRYpRQN?-)Qd<8)SP{S%%;1$qTpr3Wbf*l<5LQy@|`GzDC;7f{iy|ZmXhNVpM`fqcJ z9spL#w(Yvqsv;kh<7EMg$sjICBaJTt4^_6Wu2B`E2VW*jd+yjgpih*;f*d78@%VNLU&5`YA3>P6r9CkaN z$kZ#=k7MPRvN3BVg34$NH;CO(&wC92*nr6SA~o7@Kk^}GcM{}^k7x?Rjfb>GUv66( zboZ}h-8*|=HcaNXH?C3cs9lIl=?;+lZ|Bvr+UAQ2PaX-`zI9vszvc7WnsB2?)}A~o zf1^KrJKxpmJYS{xJl)+s??sbwdOG2sy`R5uhWw2?q&&O&v(niFdc5^qdxnTrUzf!) z{%KdPml%VIko!D&Mi)}P@GTy2soOZm{dA15!sp_czb|h+3poZ&&fyZEvZWH+)bYD>gQq#zRU^cF-AVeMf@g>&&%ayA$$0< z#ZCR~wVMLtQ=SC(x`L|h3T+G0Y1Kkpx6Yn(FcgfaY5_CkbNvnZ<72evo;43mU45H_ zfLNZc%7(gaJV>V)Pj8A1h&y~H3lL`hD8t2e@66P)h@aK-=G(=*c0ZFL0;A+Lo-`gs zZRQlRqw|!C{G9sEt&jz<1EulV65jhkDZZ0umv#Q_?bURBliv4+!*nJz>P<@ZxRD*G zPvtFTYDhwDI!OD&BnLC+850S-#(#bbY7XnUOhz09dEYnrc3YyeI)cP*@~pluZoaKI zyT#%GIwzY!2Scue_|xD&$$hE|cwS*wP~X3XX!VDbnXr*~%}w4PWTg%!X@8IutBrf^ zvwM}h$d}D;#kYX(SmoE{Tt*W{_TQ?Tb$ph_?;+&8CaNWz`@gO5FYe9w`_VW9&*4?_ z!mW}zeqS`s5xF8f1orHT{_^e8b%r1PNjkwe8ZNTkcEL1yBdG6iD{Mu7`gT!Vy440_ zFzM5(^rJxYd3-8L>hX&-{!kXHQs(m-{;`;UJ74D8+thhbxL8NC$MWB!PQPay52k;Q z-}Ba7Hw|T|~0tf6xMnhrKKtawDP9qh3UI_^Gd^ zqHGViE|}4l2gt$e|sUsv)+I@m&Dfwx)Y)>x@#bG?^Di% zwHY_@;L2k2 z(9me$Y_SYeq64@6QA<&fj?g=S4`qzW^Eb;r_h!^=!A;pZJpmC}x+Srn_58GAsJK+m1~gxIT4GG&}}cI+2zV z9s0>?4GZx-);$mc4LtIKtM6n2qCaLM!-@7oOc>}bW22`c!d^c$za3b%JfchR&p+2!T4;(w6qdPE29} zpgMxq{G^}#L&kV-mSR(Behz6Rx!sK$OE@RY?!pF4>)ad(`mq8lgQqC6sRPc@{Rs98 zR8s%PP0=Aw(J`N9a-3lZCt+TL&(swBQ=8&|cwhg?N5rAlJ3AAALILYq*VJHsrR!YserBiGfk3K-n}@0x}s;DOuc<4*-;9mc(5QlI}j2hZ90y#e^((5495FBZqJj}`|uAFA$5 z>+#B=)<^B;ceH+l@Yyf!uA61vz!p^hE$;)39%d742sBwtjv*!Cq&5=w=eh~3INE^m zi(i>O|Df3u_b;MpFT=eW9t-UiOJX>fN*6E6IqZVm!2_y%T417wQhu-gIa}WEX#cDS zrarU@+Ag-ma0K=IQa1-%BG7ptoazxHXgKOHF8+Z%?d)f_w1y*Eieg<1$9^daLguOW zQmE`eqU!PmRb{|-kF$T6DGfau4F)rA7&KIj3t;E}$x8x*=!9B6&`7Q$LK0j&#u=MQ zZJhk$%zfvcY8xlC$i%)FPRBB7MQ`vO{`W@r>cJ_0i+1YhRs0W`yT5OqILEY?VK{6! zrR63D2S%ZNc@P@!TC2r)bK#5PE+j+H2&54*e5SNtS_`l z@O?<=^B*-QMlvVhw%AHJ>?mgM>!4gK&kof*0tZnq!q#PfchIPN7@(K|@lK*KY4vOya@B_povl<3gOoxBA8DL3{JC)R*n z?RVKm|NK{TeluA{5wsRwMkfo!GVZ9i$E*?x`X}D9URKxFvde+?4=Aq~jS=S+T-Fuj zGts2}`+O8=DHx%nF?D(-(ZdmiFu0);#s{Cw^M$Jx zI!6i`@(G2Cr9ZJyTAGRf$mRSv+iaFB|A3&hfc1*wF#p8K5@*i#LGyTov5Aq|K4Xea zP@~7ETtyN{*k+?c61HM2l3Xkx(@phFMBt6Tf76RIXHLLL5{)rjF;e4ajIjr4d_UtJ z@03C`9sGYhbQ=#&IWj)((;5_$Xv|>@eg*i~qe@qnrg?A1{8Qcw+di3K+o0uQBaH`U zQH}?)D7*EH{-)Xek9-Ym{UE~zLhHqP8V}7{rGK>Lc_hF8xPnfX9?yS&)liup;HpOz-z{&|bo|+SOEIQo# zBVM)IfrdxfXo79~z&TkHd^WUM5eF23`GqOJ z3@;(3z<)>B<)52-9caEjqs~^O0ft;~2ga5TJok(r>f{ecOTY{CanphpIxBGO5eE=j zNe+5litA_WL=cGiC*e|{x2F@PsT_MK0R&SLVTy=}Ac6oL>JR>LJsl5*z3gXEiwFn_s6H_Q17>q`bZ%rVF)lJLba-?CwY_U|+g7qR`W?RlN2lsUnov}H zP2%|Y*sr_AcY77H~=V_*)#wB^wYPs7D(AjX4^FrNhGkYy?XWa z=`6EW8j6+YIGAUw7@S?EAcG@~iV|cAgLPBu`x4rkA>6sG4Q2!#OYdd|qCb zHGMPB7cG6*^?6sUt9icc+NRlul_u&|$BX8nRpk$<~= zNn1pQO-mG*({jwqRnc9@+;GsEmiD%3h{{0QwC_K^dhsg_96#`4^pa8juP3i@&Yu!V z6wP*$|1`|$g&*D=|Ge*wAIht`9ERgJSk?|tzG`VNY94|9`l=j$DL|(5e}9>ef;>Pk zoo<@fr<0t1|3>iAEb&`nc=WeTq#R#w;BjJA*-c8w(;15H>ar*OiQ_p$p z&&s?jm$dxlJflr777J`Rku>)6lFrz?BFaZw%{HD5alf*=tY&47zo#joKDDXjhfj|{ za(9LBMt4(|y`kY%eGdYo@ev#TeZe`DNLi(dhxpS%d8{(N%qBOb*BYvYMB2 zG<`Ysuu}W$&>Kx1W5+_TyAo5O`P1jLp4$BMy3v92KR-Qv_v#tWN8pU;27IELRYd(m zZ_~&|(^$20+Bs^7=F=Nv=kfVOgwM$=8rlFnm7(8w3AWfJe7N3p>$We$1z|isxt+3t z_Vtq5!h=n{mDA8~&VHi}$5@ARYJ`XZ1D(l@Q`4wHgv21PXgzR|FIrp}=sI~47wZi5fLaoU{KNs&4TU;4Ad^*sgCkh zYeVym^GU6Wt(>S>%+ZJCfxD z=@+vh8dw$$jOh|z@f>J6)F)9B-P^>TKE-wRrYjf4tR#j_7wo3DB{TUIv`h1&|LLKF z-E!~b=dP@>x{!9hnZQS9V__32s-{n74G+UyUaSfAs9#-)FWBMK&-z2H5jp|`6Q zB*VGL#&lC}*K`jJPM|xyh51S`Cv^vBGvl)fI(TyW^u-H%4WcjIR-&}zO|dFJpf?c7 zX6Ukl$hM)6aBiDniVNI@dVO1(;<3_tZJFG`>uJn5LCGI5{tW zGEFA}n%;Bbj^+CT8p8xiPm!Tx(J;{fE5kFE(Wv3FVrG1X%aP|px>O|j zLa*iyvV*@I!~$Xd(SOJJt^D|Z|5CU`ORek8CH_f70Rdq!du_{ZnFxVMBSH$bz6QNchuQ^*G zWI$}Q;uj*D4m7c=^OlauWf{E(0+hLt;6)FX#Y!4sYlhj)q7l|~PC#j-9B*nOdQyTh zQoed1`fPerznb!jMq7$)j0r?-XC*ThCPUG!W>6`Xvd{%>QFF|_pHWxK4y@e<0HHn* z2Q3Us_h;pBg@Z50aO=bvSuMkQoBeGuT(Od?rYoTix(LN|Ko8WH!Z%hW4RYR#*??^f zkT8@Q*Xy#VF?N#fnc8KXuP?z{NtW!ltFxBmdy?^+3+;qybOq`d+LoFnj=@B(SMu0C zN{hFs-up?0Oy%rHP7_;RD%?0%=cSHp)G?c8BYp_lX?oBs7WoSNGhWrL>tggETSDEi zVl;ton3jr$FF6vdAxeaSj}FI_EQlIVv%X@+Ik^=9xn^EJsdMGUEQot5Zx zNe6kzo6YKs1R|0+^+-f_o7l$WbD}Ncc&inEv1<-)^)AeqvG7*l)LyprhOWCZW-M;_ zp|(|mx-7*2lA5GIvuZ^tL|HCzLPxT_xdhzu?-E;YRv;yV%c{JR*D*9d?TIC7I@Snb z7GOeFFMO28*|Ih0}v!MT;?HX^4@rNONSZ0_hpv(Ust!8(&r zO~Ny{8F&-T1;Ya2otN|I(D$iLVl*dgGJVdBTkH$qCS6$-S$0;8@!5iqmUMZOF*v=rr(G%Xqk;>*n4wUW_&qcviQI@9>`mpxD9@g z1gN^D0m^i#$+MF9gY};I)2a*!LDFIF*)bRK4P1=td|ekZx=tLQS-)AEyM=DTc~>k3 z=Cy^Y=Xe%(e@kjfzFE&n1nli}hGWNyuCNzgMY%C{?K*TIaK)QBJ{cRxs@Z1Fr(hZ1 zEa|G1)nG2pd)1rS{j5~c%DUTUL7SiDf!=3sN5nA` zMOOy+M@AvSH}pFdeTw|~lmD2o6s0CCT9OxZHeSx261AO^v^7!vm3Hh3OjBicwg%WS zTfqWNQsV_R@Q;nHRdFT;&}jKVy|M^bMFYcH<{C=86Jf2GJ#&}dE-5|YEobuyWDk9d zrb36X>z)5%mX~xBu?l=y6%fOl?Ft9|`MWpF!Ta~ew{A^W)i5pRn~W&#WW6~%VW;{D z(N!1)xiF`b=v@+H8V!jME$w~^WLyyKrIY=2#7{@^AHl)Rc_PD zo7DV9Z;mW`1x*2)&HMl+CBGldTC!sS@Jn7r{)~k_v5r^|sj7d4uQ#xBvA3-QL!&kR z!Sscc`OpDs&-CKvGxr+~3@PN11;EuS5{CG0iH$cWXO)Dpz_yG(CU%IKgoDOCFBi-m zp)iP(&$Krh$qIKy&sLLuQ>(2uvDnavHTs~Gam4zcT$aOCn;3I1#aQ;n%Sc* zni}`QZCGa{-h>WC{%#i4awE|aYSRMOD~B1Mj9vs@nY7zQl+T-*%!`eWpng;{nzI}% zxkM(??ZR|1TDVBx4_ZEl-0YLu^TV;KEe)|rg;>ebjB9L!xS?cw=Tk_wPGm+GzNuHB zW)2zXiHRP=&a-FjgZm{szba;=la zhh7Z`AcEG_TvlD%h|`Q$0$M{?DC=a8elUO7tnqShv%&@c>iH=y4p=DyAL@l62U~*9 zR@(3>Q}cQs%x3JCX5nvDz|V;blo(6gp{|}Dm0|@e=wP-myKs5joyjBWSL@B|tv6zz zg1)5dYh-a&f0B}gcx$noye@@kpW#V0@N^M}#bajv)K+X0o(g?j&$v}jUy9Ye-nt=@ zuA|DAka`F^340tps+%IRBi3IhAFX%r)r9k{)`(~8Xc|4FNk;-6T zi41hSM*NCSk1s}XScve!rjV>Io8@pW<8+I)I8!3OxT^syXxz#3*Y1kWGU5nBx7ES% z!llY9$*7kkN%SRKDI+ho?2Mf$bHOJ20J1MHHFzV^DP4(S1sjT0w!)gIy$F=DY)Kdt zTS6tQ&;%1brX)G@yu{gUgY7eMHS{6!sz`!NqP5_&c)B}dvovAiDs|P>NxrAW3MFDpCC8D=U z`rhJ%*&QO*B){tD@?qNR_Yj{NM7h^KHyPAecO!y+>RwEl8DG5`su{CML?#AigySEG zTddVJ*ydIa-eLnz40Z)wNBm->tj#w(DKRIks&NRk1pN{9Uvi8G+gRiZ2^QfF>z092 zmrQvrUlnvz?~)8oZ9x{q8oYt!m6(<&9p;}iMO1ddU3D6m#RhS)`NYOQi?6oQ$Noiwii|Rm~P8rKJBm0rt|U$B`)OKlZ;xsGclg> z>h;@~Pk!2KCC}YTK32z1Tag-Qs~3a1X|Fg$epY#8$&T?Y$Kl34ax@%7Kqi5vMCdd$ zp0M5;+Pqg+yD}>h6fYU(OF z*eiq-;#B2TzNit4K#U@z*FesV8wTS|A};-lg=d_X^;$x{<$|CklNg3fn33vb-h|m} zJ^EYJH%vwzB8?lNj&4xPM!pX$h^j%ZhUe-Jg>ffz6}Kc|G)5RrehODKJ3MX)O%fFm z>7_b5R`LlDJ_Ez)Fl;naY|B*yNS~}w3MLo?QUKRE5Tlp9PhNM$evnloWNSpfh_4hxY z#tA8JtBd@3Q9<(hv81~`|85EfH&hxb`>fq8^Pi^q5415Wn0~~ZdDarwdOYi=n`Q>X zr?vmAJgbT(?f|ynC)DPqo42!z{9(0{-yYBTQMDTJ%RjyN={2eTEkbOIxw))=DLc{~ z@+UPNXCiXA5FQr#$KwVxRZeLj)qF~l>F?9oxi$Cl=~Ge?5!u+g+e;@)nHJwq&?C|Xmx`0QSUkCYj90C21)Qs6<+8H9e zc-2p9aW*HZKyL~}OJC%Fo#uaQ>x;5u`S0PS{{DD%KEE|xwQYA!7x#2UY%yNwcTZma z9Jlrim;7k~x}N6`=k(XKm%nI@hUrkOHu39pq1VT?I6);6U_=i2!v%iq+2a3PE{R9< zRh_@7H_KxplH)gZv5g1wgtS@A>n*8n1Me4o@OW!4>eAfQ@N)0dgo5465s2v_s~V&S zW2aiF&1)d3YAcDkYAhW7Mpi|iAISYlA}ojbWd|Xe=Rn%;*e*5fIF%-*haV`T zILNK7S(%yHO^3=s-uXdllR3!G#UH-Vz>^}8-6j&Qz!GC=!CjNAFc&y|?~!1KFsreN zm2Sco&1BRicCM4|VB$+w=7t zhjp5QhNBQ>Lt`|5U9JWgr0ERRs2y3sTQ)~__icjOe2`9eus=;fLu0g@oZSI zMx6Ri*i80Dx{SDI+@pkeRg&+N#H?DnQnnjC$8^w|WwkVpsrDVBi4In;gJgi24Df&r z@^g{gVISU@R&Ke*Bap5)ZwXt9gR3J2bF<^ zL$lSLx5f^~(AK47I`0|ClY6S z40@;|9rR)k?tuLV8J%%%jzptee^xjJcPP!vJ>I=}TMC~v*NAy|ux7!P0a++!Vb`-H zHMU;EE~c6+v!Z?C=qWQ$$R@(15P3YRLB?le5@(WM^dS$e-tNi3;K;o9!|m9@A(uiH zR7A;fNyIFFZ)n?E<4@H^X2$FZu0XitHS(;K3=8vSp{wW zx#-<6A51(N!BZr6l7(1m(;OGc31ZO(M_ryYroeev@falV$kRFeF5QR)2Tm=z`EDl4 z-~SY%JX=s8JJThGGvEe`10MQ;8h#I$KZ-Mt{Y-FpSk@10q*((BDa6RtC?8IbMo<^T z7Mh-iZ+J5^N&E{DUr-hXi98lVbvX{)6|aY;4Jn0^)W5wFd1go@*S7nthYh-#mDB9c z{JY6cefcSN>bBmQp*3M`9QB?aG*78wOoy|r+d@KW0|YTQ1iL@7>0wd9g2M)B356`6 zL1hV+{~l9Ou=z@K*LNs~Lp(vKAn5hMu`1)vaeTY5{tTknV##XaP z7-N$b*nx=8Zo4&&QiP;ts~P7=QIO0C>GiXIM5~C2v1odB92VTpp4@XJ1=92+28?b% z7(Q95ror&sf(r+K9@o`H86{A7939(nXVe<$32f@6wt}l#8eo4?7iUpDNFB{`w{6&q zB4?++#zhpxR*Y_~(Az$Lwb7XX!<n*8OEb#Uao>NF zbegsmYs0mOP=TDRh4E#Hc%1wk66PqCH1CsfGn32aC1XU?um!4gAgat%Qnl$6$t2~n z>^=AhrqZ)ce@(DcRN88`>}8gd=aPwrMO)D1zHlK4-P2^uZ+s6jTWo7NFY8{8`m9ZfunO(T)>W!nPzN4?D$2k+DV!x0VzH)AJ*wLFd%UKg6TSQhHAABz4$ zB1BnhR5RR1<`U#Gp>&f(qtt(O{eCFYCYLnCg)B(fr|#f5hA7PR(7_`LwwP!%97GW$ zKc%^M?#JKdlcPwQc_qSZVU7;zHw~vrL!_c;oyb8R01vqJ8_FbKeWD1w{9_?#QS_PQ zt;O--dTAL+;@UTO5eonkGY_LKc<7unNWNE{f)uE%`@s77{gqsz@DXz2r9~6WHl1j2 z*y95~r3cBO)&pX>ajM!(Sff%7A0#gxH(v<+?x8AYAzK~~9Qnu(edtHFIGw3HHr@PC z0zzLsKXsb?!yR#8$|&%VqoWa4n?HSa{Py)ro2jiC`pWaIcEErP8&cryen~e%aF+V`A=k z7?~ptx|cSBk{`#vYjUdRV)EE_PK=&X4I;*E3rQ^^LJm`~$QHr{;HbDc9HbOLonrKcpE78 zlULc@e9f!>&Vc=B{FCYGq+hpfeZss#Kj}8j#|Ioi%W=mLa*2xcvZH#D!Hx-GfiPIfXTE;@EbgJuoG;uV%baY-Z!mkBNbHt1-~_5Sskh~_WB$=JP%vg9Z{9v`Ey77|@6nj5Dpo83b# z03+RQGETe5XzXY<-+KhnzN>@$q98&fLLF0@48;Vx#P+cA@UIvFMB^NsgmA-}z64+k z^k8#Ez!{Ok+b1tM>VIO%G!i->5OD{|8A*0`#-hQdu&u_1My0BaI@RjvXia18EQtUs=@LN6f6i zNnTkb@p)2?8urZrxPWb@;_HBM{mx5z=d<2!EzcIw{Q5W=J{h%l)sGTq*>+-tq#-{_ z*ftf8G1x_viS!-Y6H#>b(E{_94-JN)*`m;J4)CNel2xH=n;o&d6h+@}R%>;qiv3aI z=QR&l);Pd>ghOvT_Kc2UUUnTrQ?m)E?Yhl+5Tnq3W~c+@Oi8rEkQnfU=YxN+i}hvsp!Rh2Gt#{fMLkd zaSv?t?r#v1G}lS524iB!$FUtEfw0SxYl5~2D9)NIcN1CmIKTD9r;uemSkw@e8R0|2 z;aOag95yq^d5BNHIg1QXS=H>3b9ITYPqquGC13%92&uB@qAuTC01Tg{#^K8au)@Rt zf`Pl8%{D+?j>4J(5V2mKV}nJ%S#SiRNKEG?V)yCvEY)Iqf=%6>S@zHD^JAn^%fIhj zCWSi(*SL8B@R)0C>MzhWl%d4o!=E1$@3A5X;&%{peIFZoJax0PIMaPPGpgucK(>3P7`%kyu%B0@lmUH9c? z-X2E>`}5<@7v+a|Y_iwPmOel3eSyRJ>U^W+9ad{A)8K=%RSTN;si5MEWy)f9h%!TW%OZ&#q_zNZ0Y{ zd#VnmcrW2VsVG%(9&V7|Enoz$SHaml!FgrFfn0TBt%{yInZV%XVF;0}5F%H8xst$Z zz<2YnzpK2-K?t0nwb7LT{031LN z2TE=7Hf=*aoEPOvl%WPOnagrOwxR$Isj#h3Y|ss{FG4bWI6+syk>~|Tf=fkcG|JU^ zsR-N>E|j_6t~!zC;l$}Zo~?pJC9`uXPC$77S`9G<$uSzaKgkaQ_;I!m{P@5zg2EvJ zd}eaNS*rGl1T#GyQ;`ImX^?9es$OO=1!L(%NMy>|yQq%IQ3(vEM*w;AyopA4Fu^dd z6gBb?*1AbPJMYg;t^d%7;;vQwN`;~6O$}`%oO}}a+qZT)<@A!W9|UPlVZx zQ_-w$R=`D;0`Da*wqApold47>iibR;Er1XsziqU} zRs@ICq;KiIZNSW=x{QcF?jhSrg5SvvczVpQqE+r-hE=N;!9^y)=$L{%3Z;jR>Lqbg zL`2x#GSI6>DJEGP0s6RQZ;0u^A62M2CM+AsH1}UqQ^jaCZS64vzoqPhX~ZY~E-~6A zC%Gu2z-d3*RP`W?QOH-R=Xd-^?Q|ZH@nhRHvfe$^1?L~MOcMPTZwV~W&LAuz#1iw> zZR=1BKBmY%8}V$L7O-aDA(T_rM9uil=5QP=8^CWY55S8Z#k$E7#;3p(98?9uYm!*&BTrb5T=w)Oych*9g!T3EeU~@~GGenh=_% zzWuC45>v2s#7P<|TC+iuu2lD8n-@7*RSj%VL5`VbGc)V9+1j*qB|^0it*e&Hqzz`y zZ_4)?cIu#tBHi$e)yJ{bU`(2lnrFEpMb~piGI64&O@`>eAEOBal;P40W^m~MJ96Ud z(?_R6`AVxv>>A`%S3?!FqkWuKLwNSlh>`NXV{wb%c}AhhkxZXqk(=;dstB+`$SdhKb-BrGexS?mGnp}{(#Ltsc<=O;hGdLN${7@AmK@%8w}(87i-72a}6YT@KKwT z+H&0v;u>*8cHq(cPWc{X2KIS~GE0S86>B&0cb3?}sk`tLF_tLgS{Yu|o9$0RW!=ps zJi=oP&2E5|>_s;{feN|fenzj-v{V4l07)Gj(+^sz>)LDh9rZ&DAf4@vX=f=|K&XlI5-M`N&gq zT<_$cgebz6i~(8w1vx~88fsX|o#!u~{P^9o@BS7=%Bv+_x@3?oarURip)gu&Vk+ig zvz+r^Vgb^oXgt=N&Y0yPmTLL{{LBGo41j5GCa!=iz=4F7U?b)Ui4x#(?D~@2M8>jL z{|QGhh*cwtGC&geCZ%%5ib|^_V6U;5X&K14WF1SZ3AfLbIdNft*2;^;$f6qQUnOwL zrtb3!qSzGVFlOW8{?}Aa6*&rzn~2b2KI`Ketx;OS6WTf{pR{-4MjK8~n!lrKk;z(s zBkA*~Eiq9^MzzpntXL;V1!CPpa(kwjn~Lx4@+B<{RB?EQ0627RCSJwvtq@(o;q9_4 zHKvD4CzQL`n&}n-Kco=^yl=R8-l*DJGiy88?E!Fpwv7t$gssst{1d}T8%jb7;r+uj ze^Y|1KWTsp^N|0T@*ff0?_{UZ>}|PZQ*Fl^QtzX3XOaOvTi0m-T5@3Zg+DDSA1|2$5Y0SMn?19`)8+|R4`*(7LVXX ziN`qih@)3+WW1K`SQ>z^B*%+;n6~lTL>LnntilYe>FSR(Kldx}!1pNGdko#vY$Q`S z_A0A3u^F8cPWZ6Jqq4|alhJ~8*9^OoO5JS@J2+qmx`@th0=@i||BVL?S3|Hs@(hoU zZ?cVWZvJ}fmQuw?ics-oR4f?ox(mAgg3l3umVaI9e5O6 zF#%8|)8%v$=5j*pV6k8_@sGrjq$_`d^{gyiXIbw?cb=A&E zO65TBWId4xVQYb9w+1y8o|<|;UpZ2?hpuF9=Qw0wh$|sHslx`*Jqo%wic?_(sQi~Q z3$9JAP4S?3=zx(f!i_<{M!U%Y&yJO`LH zu}8>jQN#v=Y-n`;s(R0aV6b>st$WO@dLAwe^%3VyxP=S}uer+%T0BoZ!5^wU zaVV04v=~*H4AnV$H~Jld9tyaG@e4bQ)4G%-sNc&qUFgC7n6LcMz(Ww+!ry8(Xw}uB zoS#JVuLp@#5hgdQ1!`4GJDA5N8|8VFN(Q_hv0iLQ{_J51Nx~>Ix05X+b(IW{1pM2b zWg4inJGE~z4qK$v5D@%0mPrIg8qmIClN$q*5y?8U%RQ0G#=W8Vvc?gI^hyrq!r(p| z$!4KaB?HeG_CDR={jPAtU75v?|2pYcjCCr1(4&_HUB(mHz!O9%ORX(2*wMI>Y9UEo zkt=fpom>xoFwcrr+bsJ*d^w(J9+F;_BxtID#TYbBhO-=fZ({HyE>3ag)k4f)>(I@m z21oJroyL@o76KBsEyNPQRsF=j+Hmy>TZU&YvuhZ-)E^6BI6P9-2&C$oRG%5R9)SRP zO*2nphvCYcZN}Ld(WzA#+301b*q30^adB&-j%4xa_QTWKrm-2in%7q}{KGp(8kV`u zEQeC7r;D2agV1;@<|cCEy3LBG8AsUB>Sqj@BvH^MUEWfRmsj5$ce?DaUYrVNxlf!0 z;i7RYT|WvMWqxGF;C8-|Bzdk*k5~8j4@Brs+S!WrH%@3`D|sAR2iNaYGzy!WTJn6nLMJiF8iz>+Hce+FUcFBAWJrGM-7fzIb!62;Y)N!pD( z2_Y*^bK4oHhYFrWQGBZ2^R0L@vFMY4(;CLtIFxu4x0V8+C6j=5YQ7F2Nd^0YJ$7V; zsu1NVpqf~@Y5uyYxAF3ZKxSVuWX2KE>{~Xql>~VWhhDEUJA1y3!Qj3dw+B+IG`N<> z8EshRZY1j&Du4l_?EpS{f*O;?Y`qT2@a20hQ`;vM%QbrMDfrx40{&Fby}a>TO5@49P}2p3^FFJXqnS>w<=vQ}1+;E438*{*XHLg9+vXV1?irt~F$b`{k({WJZ+d9N+G61Dsr} z^wtwom_b}?v2!+WA)lt@IuZe}kN3cAwH&*#l-g^ga}x{HGB^8HAu=}08NCRrMq?2} zU~Gb+HU65`xRZE-YtlJV?Slp55H_p)JC%$~R+cadk=4M-B9J&tU;4F>0G4q^F>P8? zz7dRYMu2nO``xI69r?@z);ZisD|0r56hYcsIazCGWm6P+k{XQ?EoRAzX6`(h$fzab zQbgEJJlBX8qThChp?8W(ZhK>OtXwl(`H4k1ssCvYMP~C8gEcN1bERr>h{CBpNL4C3 z@*zzm*(0{pZRj90R!7Svd4`i<<7RoKxe!M1Z60b7mGw5Nl}PeHV2yh#kWTifd}EU+ zjR0xlFKq;`08hc(&m)+Ij}e0ylW!(xeG=r*(Hwa>{e&@FYx}{XTiBw0MeIlsqa~6e z!jWbDK+|Qu$W;(}V1|^CAmhKmGC=HLJ(v-L&hpQWLcj-be~C*5MGCTQNJlXd{zyPb zg}TjwHHni;+$ti0Pa5GOV|E=o3vfR+<{04>B#Y5A$)n+D2Bv;ou`cOcx&h00T*~p|&T1vs#Sp~3Y?;#v7A(T1JnKwC5d<16 zV}X2oO+8e|iM=Xx0m?%C6fCc*U2&4__U;Z)Mm%c5qK<;+_#=T%&Z>ZyOme^=Xp)vK zzgF}LSlYx_W(;k1zA#Zq9FO8fiYi4jThp=igRh0BpT57St5HTc=WtLT8mwFut!$X z9R0ei<|8otY^RFtNG(JuD@NtyFf3(nid1K68e{;*`T|O}%|)oTERESH4Y`>`>s!VU zVTh2)!fkFNN+U~o`miK!`qBiO*exD1=A9jnmY~4by8{1ZR5JX89gvO$ zo@9TJfWVz^hB=t(_t)Zorna#Dae9mu2P*S;0Y@dQ8jD|1Br>z&*A8eOC`uwdFdG1 zdi7GOrOZR?L)M*QgL6t{K+}(N(|oytP0sQEovt)3Qe1P~h*W#^1WL$R-cssgjg1W~ zxG+iWS;(MvK`{S z2??0dL^_Tm@q)7+0&>WKux+dPL`Pu{AH?kM@YYfO;xm#rI2;+C5Y$R$Yv4ni+(*;+ z;oI~usPD5ufQSSSTXPe2XU&D-0mHqofc;Z?6pDxOpZL^^&sM5P7n&dFcqWcRQ;*u= z}^#sGYvm=pwlu4xN zLm$0PKOG8moYgDVoML9BeWH{KJ0wqsu0DQ3l=F-}ys&K1Sj1uQcunXVBpKTzBvD6} zBE-Q(KPSmqGgiC^z5LDfdWncCDBO~x<0*3c(5x6Yq?jMu6~>HA05G^lG|PD$Y9XF# z%agGV<9P{azhp|W%)^^%C`Rlxq^C*tLr{p<5=?T!efu>VwF%p=KFe|BPG~aFk|bIo zi1q{sH4k>sX)^x2itHvs`ou(SiVS7Qh;5KwEk6CQFl(&Tx`=@=7ExB_k-<8n`m2ED zmj{lt;lT48k?+!7!az~aFOW+t^I_(sgEE+|b>fHSF}#V}@Cgdj!@ zjS=TwEW9P4T8E_DWU5wnB&MdwxkJ7p|j znFGiszZ14&2Te0W5Dla}j~gOckHHeP4t(l&OzIS9U~}w=azOJWV*w~s5rP485@$mh z?2T-Bl#CI>xYR(O4#?5&<)axF16{-Nze1 zeYo)(_i$j}(;IK-_5jKB2_WCgwjUC_FMK_(W{NrYOUp1bq*vnO)}i%cNi?n5lR)sD zA_@|#bshZPlJtU}AN`(xV|(U&GgHW^7{1P&f_eT!$+ih&fCf>t&7Zo}lAm9+G71py z3;g93vrOX;uKyV4@23dhPmU6QDp0asMc@#~9|pLvlIkzPd4Gh^sKQqHb;IR1=>yW@ z`vkG?Rofhk9sR?u3%mq2B4xNyB@JcHh&|Fo1y79YWdf0pp6q-F1XFHCQsPbyK$#_d=C#PK0GFZVqXA)glgL%ZkTPT$D&5 z9tMC)qewh-&n#k;(#B|E#4^GcS}B*$Wu;!`=^wk#Z-4P=?(~g-p1(;U_?R((I}#QRVNsMV$JwWy zkLnNxE0T3U4NH<_CNW+f=b_+H7VD8nUAk6d{4ds5ZS6%wiPSX9EgsJyX25hhZ`#*tH~GoG~_GwTSsi6-kvcqdS4z zIiPVzNJ{WAcEkyBIl(Q<(xba<()d#4An1em$G3YCGBv>4QBRK@^;Dv-&vQ>c);^4} zz5GGKUOb}CA%#Q6@@a&?m!9VATa|>x)T#grY;GW~zzpfoQj?hR{NMlALwKzp*&G*D z*AE$sJp$zvwR5D!?L0T2V2`)a|HuxWnJb|By-f3<<%C(FZh{>LZmFPqSu$$2iz!yi zqI$0e8IGKR#o1ke{Z~KZ-C`Ler3S$_xJH7dhf9uoS z_;+T_D;_Jf#(O_m5x0kcOJn|)w0iVrFHc2f z>MgcJjIj)og;w~iN~0FFgbAM%+T?MmqmP&4%MB-$Sn3gj z{e{>?TN?J|h@K5QlfFib7@7W2zYCD_dHl(|AjRf9R3;(mLXB1|)7q^!5#vIWzc_uJ zfA!V9uS3mfM5jcsAt6LBGqz{r!5RI>Mk;lG6SpqFCI~UPl^s=wm0o@5xPs$8P4b%wqSR{>mV z@E33<6WowtBP~e9?!m2Lv1OqQqE#ms@B^VbTHA7Vp-28MCr4tx1j*zh`g?W?Ws%+f zar&l3YoQH~tTxdtO>4K5oDg{?h4&=-&#;>=tT>q4-P}!LMK=`^Fw>fl)GO*n%u7UV z(Lv|`xb()}-I7zzU(=1@l)({XZcw{QYD!+2m(5kF62U!4lFxj$Y`5doiEYTIOc&=Y ziQbfx@FcUMBr3xjZ5Kl4V&98uAA{^mPBeu~RIN2rKhe)M@D)Il%u?bqjqJE&7u`Mt zxE<-#^GBMjxa}@q(ghA&@hez82GIkDl-99s3Qy`=Boj|LLZ#O;CU8@N6eSm z&o0r~7HIl|ZOf6?!MJv=Q9an+DV{;?QYlP*bYp~&LxFBXN{>ZF1ZTP%OxcdVn+@f> zkYod|k0Ph_(1M5Ap=#f`$ru|d2{0<$yOtCA&H1cHk<9xNt)rNdWJs1CG%{@SGJ`71 z*?FU#;X2cZi>RiEl_41Db{ZngLWcG)HOlk43}iPGMYvaDka!VgjzyAyU3wVa5Rl%+ zW-fHXdQK)4n?j~}1ZK8rLJ+Bh&CtC7QdMJmf*O-?GKH0z7H}9TJj9d|qT>I69p(0? zk*e;e$~RE|k_?m>Y>Xc;TZb)-1S@l$uSKNGeCDd!G24yew}V@qh2N*2e{Khz6N7@> zF%Hf)1<6_?CFw=n@CbfszcLdW6FxsKx^*E>KY9D+NmCAjOTspMfq96ED!}Gi^s8%{ z@4MLv1}%2uOz17Md&%tl+dH!BmX}+IgbcL{E&rm8v5*8zlcl z?_loQA~ufBhlWTWn^_}W2>P~ofBPP4kv{pAejYw~`}U{&$*(J%{wv&fJApTFFyo^2=S&DufBVC%%*A> z(dCDtmI5#9+d^ECrrew^M|@XO?A_Hho1VTUq1E&!$N(_a)Tu7AcQh8*EQ zhf-ZX9FRwT_zX+LsOi)}0!@gLGLp0ce<-ioeu@MRte*+VeT3yU_m|;aEfHKbuUfTP zq?DcoisnKZT7G&6556jgUka@O=%_OyxqlhVuf*2fhsFCB^IMK~))GTm@VR<^etY&C zf?Yj?abkg*-i-UCBrh*25025ALVQud8bv&t)z`!tMznpHghzb;^yz247&cZfsDE1b&D zM#J`R47H1&e!p61wY6VQUOtz!zMl&E>qyo(t|PbE%+`DCxIh2=^bLLcd)t)K^Sf$Q z;;%FjxtWg@^B*cGnIfD|0$)I>S{CWu>L9_~drZ|9;6x((+_O=kio+FAaTpbQ4Z}x4 zD35hIt*L3L>;c}dX;ZCt)m~~HS=+vhxicU@f6h0x`@k(D4mFbKe~?HkP`-G z0e1$D#OKK?pKwx~d=zIOp7c_qD=`jvn;)KKHJHMpQ1Vh-RpGzc*JO(UAXL|Rymeoh zqR&h}puwHm_g_u#PsLAucY2q^`%%sV@GBfHWL}EHD5%f9XU^@;%PP`DCz8vT0TVK_ z46-MIKwto{pe@BhcawG$ZVlVe8We5+7!&(zyOu54%^>M?FrARQ*pgEaps3#rFwEfIW zD+5h%#U~h+{-ueztw5ekvc2HP3c)D>oM{5;{y3P7=;pW|wlowT{v;}h#W|7T;^j55 zn?KA~f@B1?#oz~CwG3?-YLLrqeoeGn6rpH~nk6p$Ll=WdN%D~1MEH>U!cmvmJ`-JTWo_(Hvr z1o=sjG^M(Q z`IQR@6L3f->~FCsg}kK*9CEQWv^8_sJu5hDt-&5AK>VSYgRzZBl9s}ifz>%yAD?%F z>njAr6`G3K?8G1m(Z!q-d)0xwqNi5sY{W0#A=X0RA*&#S#@p0S=eH^aaN-(SDq04&}RGS@BjUf z)}@1?bNlGO{yu%^YjsS^M4wC?pYy-u6oz+6xG13upBD^7#G9}6G7&R$|IXJ)EafFP zCkr4&IdaEi>lzl-q7CSetaO?+d)0;=>^ZS03qd561y>TUFFVvb&g)X5!8s^d2OTE4 zGirfqKbE&-xHKHh;Lff4_h|}QiuBo{2xmME9zIh$L(3*{S^zgdXl$n7(d?Lj7p4Nt zfkmT_`j69i8H{toMdSFZjQIf@8|U*5fMop?@B<%SuzYvHNUT|ZV8K#4@I})&Osij> zpin4P8rVY;D`r`n*R@PXi@_7PJO*4}>7q+GzE;lg?)&&tJ%xIeXq?40W6O8Oc3mk! zmOb+#(@~9fK8cy*KsoCW&NW9%KjLC_Uh*aY`{!%ia1sQg%C?$PL_0&KvF;6r!DUY5 zFmb{8MW=^nApuo_{NN|n)(k0+(Z|dryZUSAbw5tk4;h_n8V;xchrByk?T(-dRo=pm#!QSvlo&Q0#nkunH6!1#JS3xGg{~Ur#n>SaKzs+|I4bR^n1+GRCKoS3Q`IJ5ox{$u;wD3V0qvS z7>Dt1>h-p=MWV8bppx)4)t>N=J)i@lF!^)2T{ePL!2e`oT=s+`VB%jzupOj7f zX3Dlc_U3tuGwOC@$kcTmH|qtyd#%VjCdX^rEt>3o(z2nRptY%4 zqy*H$3jJWb7Te`w(U=J0jGPY`8+d!@*_!hmrF${O#~T_Qhv29k5u^Lj<8yY%A|ebz zQOQD=DU!|+KjfI^4g=FD6s>AnHzFp!CD-z-u)f$H*3e#ih?mH_9ld`W?N zU|EzMcufGd<{EM~kUI}%LtWOxu7w2E$b57(|IHv3cF41&)h)r*pVFGWaF+zb7FiuS4cl6jZDj zmt51p@nX$x8w!9|;}SduSwE4oJ30pqRuxD;j<2?mMN2P3*?X}zlsjR=4#gJ@#RG|T zOwoeedyx7J9C%beFrN`3b?AZ`HWgPjjUp+r8Fm8ftQcgd6>|0T6PuiI+aw-*5<-7A z!`dMH^sA^?iY0E?9PU3*_eMA_Mk_Y3-Xc-v<*L=zLIOTrc$bycYmAaycWTJ-4P#>` z8kS?haGU4tmAoH{4QO6vG}130jNC5Qa4KF?Pw7L(PhAk7T1e(208*9>lVYJh)^xqU zR7>)}mv$6IT)rQy-V5krRm{59qjLl26G|KLrmr4c;}{YhFX4en=z^sd???F$#Ud23 z(fE-@Wip6`sNgA~X^k#MhjgDrvV%cf8iVlz?svf`wTM1*{BoP>*AH&&;R+-dm7hr~ z&%p4n!;VjE6dNG^U9P|3QFIR&J}D|%=b?OQX^x$^0*{i@LmRc>!RI{C@;#lsUQid$ zw%K)|Fw<)sf?=5*c;4m8r~-&UO;5s~QlwxK@?0@zt_mjAjiO>5e)H^&OOu@1Q0D0- zg3KquVU75B*gxNfh!4*T;yw+tpV8K2V}SnFP0GG$La@#83`y@CT>!YBaL}fsYJ`<$ zd|0=9$y&MHa+v3bQVqOnrhhpyAvB}EBpYU~*@4qV1%M~{vs=&1U8jw*z^^&3bhWIC zb*Amovr)tRXS3+J9sJJwuj)}>jwfRv=X1fM#*y#L{OMJGd$GW9777Bo4;WS&b(!+p z2l*j;Km}EVpOl1(=%G9GkZzAy=IEJB^&>ivH+K4<{IvNKg&SrA~(fB6EO8@qIi6KeVv$i zU)GmpuSwpQ0!Ys_;OXK5d(A>3)t<_DS0UQ_teC^OjQpNA0wv@nYwc#guU-?D0ubfH zj`M!D=?#}DOj7sI5R4F;_8aDOG}TDdHMvQc#_N2fYf76vEZmi2Qe1`*DwhrKKH3-=}qD_YC|%1 zrjgj=)s1ag?COYNEY0)e?%n)pW*r&YP$1!vSJfE?dMbowN4#`g@)nB?mO&KQ3aSNfZZ z-EzTzF98el+AuZKOb=U>%qr|!9F||I0faBx6_SZD-_zCQ5%5p?Ph+@+c zT-9XsTz|!(VmuAP;*5c=>7m0HA^*KydPMQk4tg_BOyHj%%c){L?A57h%#q*;_KL?U z%golgHjEu>QFW)9&3*Xl#p#jf`}s&5QZqj-E*+jq!j)%TA<#@D4K9y2Ynfm9o`ISx zB$98;*CDmjItvz)S|CkS7FF0Y|lb*F0@}JJ0}K*u?<7U7~c(GX=biSsS;a8Te%c102uHr;W1L8 zK`%SDdu9d>)@{|+D^_L<((GqD(A!aZTe0;H>!Rm7ht?VINU_~hM6 z__6_nqh~Hg5W&QH4rTNi(oLtjs#PDwFv*?SNXUa%Cas1%28I+=X%6w0st^iP`CWj_ zkwOHxHmc2)B7Slvhp;!{5^teW5h@&h9xZ){G z%~l~G0sphuP9zv2+Gi+3iB^LG6tpcb@4$vT0kB0wFe$~wZ$nKu#cT;;OCDqFvwr}} z2eMyrQwY|+MBdLgiow?dZ*YI}n)@P9{wUB0WA#;18a4EHgaoN8#19BTjSx8-0 zLrkqGM>s>WJdy0`grrh#0JfsT1VqA|8p=S~e3Za}B^AMx6ORWR6W=UqU zUv%-@${kQS6g;&v%HbXo3d>$O0WI=dWyk1p&W1QF+Xl4^OnkB97TMsEdJQjz52t(j z`vFhdwK#`f&Rk1?Ss|^RK$D}{Zoub!h*IXrT9-2q7hCNY44XNVXS2XKLUI7(zoBWo zh03B)HicRhV?+3!R5(vAJb8#K?2#w?86Gz8PP!~9iG_SbBrn4&!{X3!Rspc}yPuxB z8Lsz2IWyc+r6TSRU5jJk2v~Rp-zXw2XOar)K72;go2Db&`Qp=vOShG3RdRXo5y2%X zxjmv;tvcCDnJ2AC7AH>k0k6?3R7M3NQr@G`R|t_2cP=rF85=GnPJ28|czZo|JVJ(y zSbrf*oSCDVJ|d*pED`39;vy%Y4fVCfi^cT~II$;Ltjt`zh77EJ`BDAS81br>GSH)R zqKxTJR*fqy1QhguNZo4cmKrY2jroS_+pKmYCqmaAcC6D;PGENHC%oiM8?SmYPifBZ zz6F0%-1;m>2~|T-V|Od3HWdCI2hnq~&_KFM+NUCheXv_U>@s*$m6N20XsbN2l9r_g zW(y;&c=a!2IBI%>(@_#)V&1VBH86T9P8%?f*!P@#M2&5ly=O_tQ#=N69dpU>-fd?L z5q#^Bg@G^yO?10v=VBArMoq1Ys};xIaB1uIqZ6aViGn=n=hzGF&Qb>CFTNw~A?UJg z!@e&mm?h}YjgF~L6HQ!v^ZiLeWjquK?)Hf(=D%Rn)N8mqSG-dwi`eOe z%P>L|E$3B{9TvGDh>mK5O=LWth7ec2GbrBCoTlj|6xSZ$vYgCh1#<2Q78o85YnC^kFb%E_FZiplSl}5T#f9F7^mSsl$ZI` ziYd2ejGWp`LJ|FjbVnY0giQ)?)rb5c#{lwtS=B%C@bMKB*F`Bxmb)q-wnRZ?$$8P6 zW3k~dt+Y6c2ID9s3+&gHETahdEVilaV5YKH;g|BPkKK6%HkUD*lP1{B8&Ff2UrGtvSFgs(r9eZ8PCEgzGDuW_>toy+ z8~)vB_{@8w@e41$ZUP?~ykwmak7m0g{CF3bGXN$9-K~0if@)khV)4y_W~bVj{vS;uVO$jpGrEff-~EnaBVmGqS2uFv*2zF3KI zNIlzfIL*~lb@{vRetrJ>)w|O;tJN3QqgSgwsaK2s_(J-z=<57iy3)3vae2N>qab46 z3(tHptf#Ynx>=n~%lYQP3F+n-Cvk!o3$JL22IAYw0(2(HB93oJOf*LI-oKP1tc~fB z20`1-xe;>512w;_*8PPLiFp2|>kBv9WU|idi<5^E`uFJMAwH4|U3Fl8<|$3JdHUQ4=gYP~U$E0x^Vn{H`q>6VsoO5hekKu)IbiV-NWIgXx|G*PGN zd`h3whE9oKGNtXd3o#uoaz;35LO_Pf#qM}+15NA+x86tJxa{{QG~S-Fnj~l%vN;K{ zF`@DBK(RzD<$Qm^0hBl{k2%9V4^|VV-u&lRFMiEOE=C%va1IG_@qRLn3r49$g9ww_ z4J`J+rm$&9WxZJ@MT~YK>`EMl`Cag-he1WvCo-}3bOGK?!%O0TgEB%GjA8|n92Nza!n9PQ#t7Hd zT+wLv1_C*T)9d z^=Qi?I5aQ)0S-0$oJLtDNlnqK zX^oej!LKbCJ?cP9W0xo)6>4KUu}D>*s0^hRlx&mFfDdaDYKDSvdmIEGVKNuOXa-o!VUJ$7*s*vF8yb(9O>?MX>$JY*T#UiA35mK065E zTjGtf7$CLfIv#{7&pRuamK6En*|&^~%TEY8o;0MB$M@QD)u+;{I?o-Pgx3A=&5LJ8 z2L{>N$h%7g{Qbn8N)$IPD&MAZCN9WDjFr zCFO_RC1)u|u=GUdIx=~VcrDk9PbAwU>MqObq8~K41YV48E?_RwM-|ep*wwOvk8Q~& zGRy0;Px#8A59uw^^FriBXjB$*S!o6l{R-eSqbAtHkxC5|@PgJP5%)AHL|>PpgqY zLXFD#tR?`n!%S3j4bhWwNF%sB7ER=9hQHeDw9dj1<7dVFI&NX43i4-sB&!A81tcji zHGK!tjljdvve*b|Nxrfrp_U%}@vtU7h97?m4q=WlLSZV82j^JyO_Tj+$!@SW;&A=X zH%FpvSo%W2cXrGGwh@T3ZUv1X)5Yi+1^Y}e`Q)ZLh`TrtSc$G&LeRuL3DgRbENKcP z-0VYT5omB_iB_5K9r0yVH7r_tUC$<(ceBk@Y?2^+1tmm<_ljeUW%<9()4J1$r1+!J zVb{`bAGMTNNT4Zfn({rWL&9~#81*i7mhUIjEN7I6QaPi^n~{r?Y?P(YVBc<2dB zA~;IL@iNU#$qN;=_sVQU;9s^Uo4aP&CiD*vrLQ!HC;fX(f2 zS9^I)wN!u%ElW#M-zJFBJU(M(S86=;-psfKug z%4&Ij)^=P$s);*RU1_5yJzA06e;WeA-Pcwh=Z&SrB`t0lhE}WB24CHr^R$a!JG8CZK!*b zxt71ffX9Uw#Po4mmJyQ*U>@1XCUxu9G&yW1w4m`G;cx8Ib*qcrdZ={%NX9Rdi}J1X zYvGSUiDp>$HDYep^Qi=uUpp%w%XCj8taf@vZ<(J$svI#UoXt|*~ ziKZe$g3%@O(idD%$32qX9rVR#qlzLnV6az9Sk56_HUdSSA4pmqs>FK1i&fE(sCppk z$flRbDNe%bq51=9M1t>0_%9f8960dQ4I3;v@nWE zB!F@_y+HXPTf;ANkIW#Aw38J3fX6=N9*JlCq8`idEG7N_)AEc>e+8MBWXlNIq7}-S zsN{wF6p{Q$jYZ9Eh@kAznP+0C7V~@r#!Ux8@;$Z^tH$@EB|57YQ#0rU79grdXv(p; zk_!X!hzb^3C~@z|9qe!|hD@>tle)W&yRS*Fm-V>q8Bz!X$zH`!Djcf=&8u;|8P4jV zxe3s!WbJ6TMI&UJc_K)ZmKBNtj?0`0*~+TLPo))TVrR(}=O~iw%HG&tXtPTI{YVXH z?@{xfi|jyAKlEtpWR@KV=1FZvUOpD1xV{^UfQW!R@_m|S-)c&SIeTLKoBhrg&PCKn zgAi_&VGu$Z9u$!>{MeM4a9r~R@T38E&t0p?9(141gdSVC=93R^l_Q>r1_#-L;sWQoG?OC8QRvmYTSIZ z|NAE;@>~cl0cP>;d<4aTdV;s5V|y$qaE$aI1x3@|eRiX|I7!Kt6wfK?4!98mqydJS zn22Pc01=_TUpP2!Fl6GsEZMER5Y-7|kE*hj^UIPHv8XGsAoB+vYL2qENp1Cj%sy85UUg{+B9_ONNH0sy-1bg> zJ+Opdq&qH?2+bjqXWZ_6UASgiw2S1MV@-<~wEpBI)Vz#@7p2+!30Gl_pdgY=?~s5Q z_umH>pk>KOGDEg5*o$J}-ds6eLm5ho2C@8fxeU^FaU@&1HCnq1BAN+|-yz6PakdQ*5~L7S&hvcV%v zWU3tA=WcfeETLl6tW&RSCjn|%A)>TfvRB(GOtC=H?TB33pHdpy%b^X@T0BIw>=ksjWP*6 zb3hTWO1T3if<<5CD!p8u9c~m$EtaZa6|&T10tGE=Gjs~#Xed+G++|f{ub!VyVzA_y zo5JJSCLu!xF^B`9AxWr$Au9hF1F|d0I)ssi9xm7m#?^q);se3<5zQbQ#W+Se1((p6 z<<{V|JYJM*a{e>%-zj92#(1_S`>F$-xq?D^S@@6w4oK3tqw}-ggk6(V>R5@6IFY6` zF|CB1#J036mV;Um5*Xl`D6qpOLW#34Qk4%`37O%|V=WGFeh-B8AmAgtjdQFR(NGY>(Q(EZ_E9|wZJY7SX{R1!>P@)hKrJ74 zWnD3hqL(bGW|<@P$O!Gti3#DXn)gVWMCbtDThx{+d}%8a&$%o}8b2=wHo@5~&$~7s z!D-6fbI;1NvjC?jE}$E#5EMIB3^0U`H{VV0-jSAp0J5SNokPu2rbEJa8-u7fR{MWx+v3>_*FiHrJI_#uqo>7B16S zNb(IC!=T(y^O3gsTM{0!S|KX7&CCTWM4qx>LY;iWLVmxqvYLEqKvvlZP;nx~mCdOm zAWOLx`TmI)Cq=hJGnVz8imLtfyL#B4Lo=-CURhl%XeSmuj7GzzDe)Jx=SjZNpZ!&_ z<}4QcTr4K}vK(m9Zz%bG66|W#pB>hLO;*p4gadRD7R*lq2IdIsNg{PiM*IkibfP5S z3#RZ{0Xia(j_Qw45*Ap*qR&{ZD*BzgHTM78i&i3A?yjj@wj47M7=xi$Nb8u*qTTYv zy`U+sw*rC;9DIa|m^FfjJ+f*{B2!A3OQaHV0^tC%h$yCz46bPmt}52&fZLbWh`iCi zn-I*W!3d>oP%OfgI=qpFcI_9jub9^Vp`cnUdRoc(Fg9Ac!D}*RZ!$ ziqjT2i3*|kk6%?6#Mz7K`DU0dsz=$uOX~iZ2;#uVNQVVtY08?@cUpF-3W~aWMge+I zsxuN^#)tR_JT(kd_}W=J-{uETo;}Os=^RM5<7RP1UUrzIgV5jI{)8fqD;=E)2ZXLUJW@-38Q zPf2vEhEPhLVV#30<6&}9SHA5NxKfl$P4@FAIi`{scBMDKdL#4|0BbGeGy>&(AwrAY z2Ji)4h&NC9P&6@aIzt8{S4hP3oHaf%usc;PLR8YbV7bHjz>!MI;i6rqgO*8de#&M$A!P zD+@_>E6bjB3k%H}+shy84L zJfHRSy-hiboO$W$eoLD=N7(5Um?~!_m(zN9))$X27GE{z(<_804l>oZ)kXfi06&fX zJzU_E$HN<@w`&y_wIqQ&QAvnmn}UPzPU4Nuq7?AIsIc#DYJ( zD(d04@-gh7t72KrWKsUwo;UfEDQ>yJYs5eNZN-1m5cIL9=jirjIna&1@Nur>@5eO_ z)mM*cVbjeW15wCfB_BPWmuEy8GJDy+r_=mZRjw*~w80?-x@NE*|}X3*V6~ zZ}P&^*RS4vhZNV0>m+I@XFmP&|MJ`DlmjbkLaE>gghUCs|kChMm4E=V{Uzg z-CdCw8PDAtLQco3!CJp$Kc5(&S+>(ynaaGD77VYNnl*G^8bT%nVu*7uUcoYhg)c{O zIG0ri45V17i5o&pe<$1jL%ci^zsBEuaFx8FTVLc>%i=UGT9F_6Zw%pi0VBBj1dpOM z`cfOZm20Hd2+uXYDII+cD0D#@hK1OXhX3$cz0GI!?$nU+Ie(Z2HmXlH$^WJxUo`f& z0wtK=&*O$}NkazD{wwebZ`RH|81M7A>?vV#fj{T6ZpN}@~ z4c*m-P!N||`UQz#tP|dJzi!`_hVJFTYyN;y0*~3=cjI$!4c*TZgm-YHgsNRIPH@+! zffR4wk%qp^9seM=8d(+qY9*%(K-A65$%wR}ukzUGpg4}9R$>0}HM%DaeH{u#GJlNV z!EU(N+7OQGA1*(Wkn~sD(5*jEHDVtFx&5^^bo-jp1vjRnuNh)|7h(JlpZhy}?*Bd1 z*gS6N&jWepI-*sL#+kd55Lw_1(z;2>Dcch_f6XS2XZPw5YlWFshHgs*`Dv}fU(>}LqbuyL_gvzx{oK(2 z_MZvp&Xa}^di#;c+x#ZW%J=d$LACiG*&l5viAK%;%tmWNHw(1NKi<$zyh#2>NA#sM c^g-ueezS)DmpuSP?I8F6A0W;oZq#T20K+bo82|tP literal 0 HcmV?d00001 diff --git a/libc6-migration.txt b/libc6-migration.txt new file mode 100644 index 0000000..7c8134f --- /dev/null +++ b/libc6-migration.txt @@ -0,0 +1,263 @@ + + Debian library policy supplement draft for libc5->libc6 migration + + This document is meant to tell what a Debian package providing a + library should do to support both libc6 (glibc2) and libc5. + Note that these requirements are for Debian 2.0 (codename hamm). + + Contents + 1. Run time packages + 2. Development packages + 3. Source packages + 4. Requirements on libraries for Debian 2.0 + 5. Conflicts and Dependencies + 6. Handling bugfix releases for Debian 1.3 (bo) + 7. Requirements on compiler packages + + 1. Run time packages + + A package providing a shared library has to support both C library + packages, libc5 and libc6 based libraries. This must be done using + two Debian packages, each depending on the correct C library + package. + The package naming convention currently suggests to name these + packages as follows. Some packages (mostly from base) may use + locations in /lib. + + based on | package name | library location + -------------------------------------------- + libc6 | libfoog [1]| /usr/lib/libfoo.so. + libc5 | libfoo | /usr/lib/libc5-compat/libfoo.so. [2] + + If a library runtime package contains files that are needed by + both versions of the library, a new package should be made for + just these files that both other packages depend on. + + This package naming convention does _not_ apply if a package uses + different sonames for libc5 and libc6 based packages + + There are two exceptions from this rule. The shared linker + ld-linux.so.1 and the C library files libc.so.5 and libm.so.5 + should still be located in /lib, not in /lib/libc5-compat. + + Packages based on X have to use /usr/X11R6 as prefix, not /usr. + Note that the X libraries are designed to work with both C libraries. + + 2. Development packages + + The Debian policy requires that all files needed for compiling/linking + other packages with the library are in a separate package, the + development package. Up to now this package simply was called + libfoo-dev. As packages based on libc5 and libc6 usually cannot + use the same development files there has to be a clear statement + how to separate these. So for now the following packages are + required: + + based on | package name | hierarchy locations + --------------------------------------------------------------- + libc6 | libfoog-dev | /usr/{lib,include} + libc5 | libfoo-altdev | /usr/-linuxlibc1/{lib,include} + + Note that usually is i486, but may not be hardcoded in + debian/rules. It should be obtained using + dpkg --print-gnu-build-architecture + + Remember that the libfoo-altdev package has to include symlinks + /usr/-linuxlibc1/lib/libfoo.so -> /usr/lib/libc5-compat/libfoo.so. + to enable using the shared libraries when compiling. + + All documentation that is not depending on whether the library was + compiled for libc5 or for libc6 should be either part of the + libfoog-dev package or be put into a separate package if it is + large. In particular this includes manpages which _have_ to be part + of the libfoog-dev package. + + Note that the choice to base Debian 2.0 on libc6 fixed the fact + that the main locations will be used for libc6 packages. The + alternate locations are used for libc5 based packages. + This decision does not necessarily mean that by default the + compiler uses the libc6 packages, please read section 4 for more + information. Using a four-way approach for library locations + (standard and alternate locations for libc6 and libc5 based + packages) will make Debian systems inconsistent with each other, + something we should avoid at (nearly) all costs. + + + 3. Source packages + + The source package name should _not_ be modified for hamm. + + If a bugfix for bo has to be released, use bo's source package to + extract the bo source and add for each hamm release a line to + debian/changelog stating that this release was a hamm release. + Make your bugfix changes, including changes to the control file + according to section 6. + + Then unpack the hamm source again, update debian/changelog and + debian/control to figure the bo release, and release a new hamm + package (including the bugfix, if it affects hamm as well). [3] + + 4. Requirements on libraries for Debian 2.0 + + Libraries (regardless of which library they're compiled against) need + to have runtime dependencies on one of libc, libdl or libm to enable + the shared linker to determine which library to use for a binary. + These runtime dependencies are _NOT_ dependencies in the Debian + way, but dependencies generated by the linker when generating the + shared library. See the binutils manual for more information. + + In general we want libraries compiled for libc6 to be thread-safe. + This is, however, not practical or feasible for every library + package. Making a library thread-safe involves quite a lot of work, + much of it nontrivial. + Thread-safe means that the following changes must be made to the + library packages: + + - compile the library using -D_REENTRANT or -D_THREAD_SAFE + - there may be no permanent data residing in the library memory that + can be different for different threads. + this means in the first place no static or global variables that + are not in some way protected from access by a different threads + via mutexes. + - all write access to files from a library must be both protected + using some file locking mechanism in addition to using mutexes. + - at least some library functions must be protected from being + used at the same time by two threads sharing the same memory + space. This is done using mutexes. + + As these usually are all nontrivial changes to a library if it isn't + thread-safe already (in which case just using -D_REENTRANT should + be used in addition to whatever the library uses to support threads), + I suggest that no-one starts doing this without getting in contact with + the upstream maintainer(s). + + If a library has a thread-safe version, the debian package should + use this. The performance deficits usually are very small when not + linking to libpthreads so only if there are serious reasons, the + debian package may include the non-thread-safe version. + + There will be a list available that lists all libraries part of + Debian and their current status regarding compliance with these + standard requirements. This list will be posted regularly to + debian-devel by Helmut Geyer . + + 5. Conflicts & Dependencies for hamm packages + + The libfoog package _has_ to conflict with all versions of the + libfoo package before it was made to use the libc5-compat + directory. Furthermore it should depend on libc6. + + The libfoog-dev package must depend on libc6-dev and the libfoog + package of the same release. It has to conflict with the libfoo-dev + package. + + The hamm libfoo package has to depend on libc6 and has to conflict + with libfoo-dev and libc5-dev. + + The libfoo-altdev package has to depend on the libc5-altdev and + libfoo package of the same release. + + 6. Handling bugfixes for Debian 1.3 (bo) + + Using the dependencies from Section 5. there will be problems with + making bugfix releases for bo. These have to be handled carefully + as otherwise there may be tremendous problems for people using + hamm systems. + As there is one package name used for both hamm and bo that stays + the same (libfoo), we have to very careful. + The following steps should be followed: + + i) when making a bo bugfix release, be sure to make a hamm release + at the same time, using a higher release number for the hamm + release. Update the hamm package's conflicts according to + section 5. + ii) Any bo package for libfoo _has_ to conflict with libc6, + libfoo-altdev and libfoog. + iii)The libfoo-dev package has to conflict with libc5-altdev and + has to depend on libc5-dev. + + + 7. Requirements on compiler packages + + The compiler and binutils packages have to provide working + development environments for both C libraries. Basically (that is + from the compiler standpoint) there is no real difference between + the two environments, only some paths and automatic definitions + have to be changed. All this can be done (and is in fact done) by + supplying a different specs file in a different location. + + The gcc packages do this as follows: + + The gcc package uses libc6 by default and is installed in /usr/bin. + + The alt-gcc package uses libc5 by default and is located in + /usr/i486-linuxlibc1/bin. By prepending this to the path this can + be made the default. + + These requirements are fulfilled by the current gcc packages. + +Remarks: + + [1] the name of a library package often includes the major version + number of the library. If so, the 'g' should come before this + number, e.g. libgdbmg1 as package name for the libc6 based + runtime package for libgdbm. + + [2] The location ../libc5-compat was introduced in the ldso package. As + ldso is a package on all linus distributions we'll keep it for + compatibility with other distributions even though + /usr/i486-linuxlibc1/lib would be more consistent. + + [3] An example for relevant sections of the changelogs for a bugfix + release for both bo and hamm (with the last bo release being + libfoo 1.7.54-6 released on Mon, 16 Jun 1997 and the last hamm + release being libfoo 1.7.54-8 released on Wed, 18 Jun 1997): + +-=-=-=-=-=-=-=-=-= bo changelog =-=-=-=-=-=-=-=-=- +libfoo (1.7.54-9) stable; urgency=low + + * fixed bug #543547884 + + -- J.D. Maintainer Fri, 20 Jun 1997 08:32:03 +0200 + +libfoo (1.7.54-8) unstable; urgency=low + + * hamm release + + -- J.D. Maintainer Fri, 20 Jun 1997 08:32:03 +0200 + +libfoo (1.7.54-7) unstable; urgency=low + + * hamm release + + -- J.D. Maintainer Fri, 20 Jun 1997 08:32:03 +0200 + +libfoo (1.7.54-6) stable; urgency=low + + * added handling of bar. + + -- J.D. Maintainer Mon, 16 Jun 1997 18:45:14 +0200 +-=-=-=-=-=-=-=-=-= hamm changelog =-=-=-=-=-=-=-=-=- +libfoo (1.7.54-10) unstable; urgency=low + + * fixed bug #543547884 + + -- J.D. Maintainer Fri, 20 Jun 1997 08:52:09 +0200 + +libfoo (1.7.54-9) stable; urgency=low + + * bo release + + -- J.D. Maintainer Fri, 20 Jun 1997 08:52:09 +0200 + +libfoo (1.7.54-8) unstable; urgency=low + + * finally made package compliant with those strange policy for hamm + libs. + + -- J.D. Maintainer Wed, 18 Jun 1997 15:34:12 +0200 +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +-- +Helmut Geyer Helmut.Geyer@iwr.uni-heidelberg.de +public PGP key available : finger geyer@saturn.iwr.uni-heidelberg.de + diff --git a/packaging-manual.desc b/packaging-manual.desc new file mode 100644 index 0000000..434cc2c --- /dev/null +++ b/packaging-manual.desc @@ -0,0 +1,19 @@ +Document: packaging-manual +Title: Debian Packaging Manual +Author: Ian Jackson +Abstract: This manual describes the technical aspects of creating Debian binary + and source packages. It also documents the interface between + dselect and its access method scripts. It does not deal with + the Debian Project policy requirements, and it assumes familiarity + with dpkg's functions from the system administrator's perspective. +Section: Apps/Programming + +Format: debiandoc-sgml +Files: /usr/doc/packaging-manual/packaging.sgml.gz + +Format: text +Files: /usr/doc/packaging-manual/packaging.text.gz + +Format: HTML +Index: /usr/doc/packaging-manual/packaging.html/index.html +Files: /usr/doc/packaging-manual/packaging.html/*.html diff --git a/packaging.sgml b/packaging.sgml new file mode 100644 index 0000000..4a3f0a5 --- /dev/null +++ b/packaging.sgml @@ -0,0 +1,3574 @@ + + + + + + +Debian Packaging Manual +<author>Ian Jackson <email/ijackson@gnu.ai.mit.edu/ +<author>Revised: David A. Morris <email/bweaver@debian.org/ +<author>Maintainer: Christian Schwarz <email/schwarz@debian.org/ +<version>version 2.4.1.0, 14 April 1998 + +<abstract> +This manual describes the technical aspects of creating Debian binary +and source packages. It also documents the interface between +<prgn/dselect/ and its access method scripts. It does not deal with +the Debian Project policy requirements, and it assumes familiarity +with <prgn/dpkg/'s functions from the system administrator's +perspective. + +<copyright>Copyright ©1996 Ian Jackson. +<p> + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. +<p> + +This is distributed in the hope that it will be useful, but +<em>without any warranty</em>; without even the implied warranty of +merchantability or fitness for a particular purpose. See the GNU +General Public License for more details. +<p> + +A copy of the GNU General Public License is available as +<tt>/usr/doc/copyright/GPL</tt> in the Debian GNU/Linux +distribution or on the World Wide Web at +<tt>http://www.gnu.org/copyleft/gpl.html</tt>. You can also obtain it +by writing to the Free Software Foundation, Inc., 59 Temple Place - +Suite 330, Boston, MA 02111-1307, USA. +<p> + +<toc sect> + +<!-- Describes the technical interface between a package and dpkg. + +How to safely put shared libraries in a package. Details of dpkg's +handling of individual files. Sections on when to use which feature +(eg Replaces vs. Replaces/Conflicts vs. update-alternatives +vs. diversions) Cross-references to the policy document (see below) +where appropriate. Description of the interface between dselect and +its access methods. Hints on where to start with a new package (ie, +the hello package). What to do about file aliasing. + +file aliasing + +Manpages are required for: update-rc.d, diversions, +update-alternatives, install-info in a package. + +--> + +<chapt id="scope">Introduction and scope of this manual +<p> + +<prgn/dpkg/ is a suite of programs for creating binary package files +and installing and removing them on Unix systems.<footnote><prgn/dpkg/ +is targetted primarily at Debian GNU/Linux, but may work on or be +ported to other systems.</footnote> +<p> + +The binary packages are designed for the management of installed +executable programs (usually compiled binaries) and their associated +data, though source code examples and documentation are provided as +part of some packages. +<p> + +This manual describes the technical aspects of creating Debian binary +packages (<tt/.deb/ files). It documents the behaviour of the +package management programs <prgn/dpkg/, <prgn/dselect/ et al. and and the +way they interact with packages. +<p> + +It also documents the interaction between <prgn/dselect/'s core and the +access method scripts it uses to actually install the selected +packages, and describes how to create a new access method. +<p> + +This manual does not go into detail about the options and usage of the +package building and installation tools. It should therefore be read +in conjuction with those programs' manpages. +<p> + +The utility programs which are provided with <prgn/dpkg/ for managing +various system configuration and similar issues, such as +<prgn/update-rc.d/ and <prgn/install-info/, are not described in +detail here - please see their manpages. +<p> + +It does <em/not/ describe the policy requirements imposed on Debian +packages, such as the permissions on files and directories, +documentation requirements, upload procedure, and so on. You should +see the Debian packaging policy manual for these details. (Many of +them will probably turn out to be helpful even if you don't plan to +upload your package and make it available as part of the +distribution.) +<p> + +It is assumed that the reader is reasonably familiar with the +<prgn/dpkg/ System Administrators' manual. Unfortunately this manual +does not yet exist. +<p> + +The Debian version of the FSF's GNU hello program is provided as an +example for people wishing to create Debian packages. The Debian +<prgn/debmake/ package is recommended as a very helpful tool in +creating and maintaining Debian packages. However, while the tools and +examples are helpful, they do not replace the need to read and follow +the Policy and Programmer's Manual. + +<chapt id="binarypkg">Binary packages +<p> + +The binary package has two main sections. The first part consists of +various control information files and scripts used by <prgn/dpkg/ when +installing and removing. See <ref id="controlarea">. +<p> + +The second part is an archive containing the files and directories to +be installed. +<p> + +In the future binary packages may also contain other components, such +as checksums and digital signatures. The format for the archive is +described in full in the <tt>deb(5)</> manpage. + + +<sect id="bincreating">Creating package files - <prgn/dpkg-deb/ +<p> + +All manipulation of binary package files is done by <prgn/dpkg-deb/; +it's the only program that has knowledge of the format. +(<prgn/dpkg-deb/ may be invoked by calling <prgn/dpkg/, as <prgn/dpkg/ will +spot that the options requested are appropriate to <prgn/dpkg-deb/ and +invoke that instead with the same arguments.) +<p> + +In order to create a binary package you must make a directory tree +which contains all the files and directories you want to have in the +filesystem data part of the package. In Debian-format source packages +this directory is usually <tt>debian/tmp</tt>, relative to the top of +the package's source tree. +<p> + +They should have the locations (relative to the root of the directory +tree you're constructing) ownerships and permissions which you want +them to have on the system when they are installed. +<p> + +With current versions of <prgn/dpkg/ the uid/username and gid/groupname +mappings for the users and groups being used should be the same on the +system where the package is built and the one where it is installed. +<p> + +You need to add one special directory to the root of the miniature +filesystem tree you're creating: <prgn/DEBIAN/. It should contain the +control information files, notably the binary package control file +(see <ref id="controlfile">). +<p> + +The <prgn/DEBIAN/ directory will not appear in the filesystem archive of +the package, and so won't be installed by <prgn/dpkg/ when the package +is installed. +<p> + +When you've prepared the package, you should invoke: +<example> +dpkg --build <var/directory/ +</example> +<p> + +This will build the package in <tt/<var/directory/.deb/. +(<prgn/dpkg/ knows that <tt/--build/ is a <prgn/dpkg-deb/ option, so it +invokes <prgn/dpkg-deb/ with the same arguments to build the package.) +<p> + +See the manpage <manref name="dpkg-deb" section=8> for details of how +to examine the contents of this newly-created file. You may find the +output of following commands enlightening: +<example> +dpkg-deb --info <var/filename/.deb +dpkg-deb --contents <var/filename/.deb +dpkg --contents <var/filename/.deb +</example> +To view the copyright file for a package you could use this command: +<example> +dpkg --fsys-tarfile <var/filename/.deb | tar xof usr/doc/<var/\*/copyright | less +</example> + +<sect id="controlarea">Package control information files +<p> + +The control information portion of a binary package is a collection of +files with names known to <prgn/dpkg/. It will treat the contents of +these files specially - some of them contain information used by +<prgn/dpkg/ when installing or removing the package; others are scripts +which the package maintainer wants <prgn/dpkg/ to run. +<p> + +It is possible to put other files in the package control area, but +this is not generally a good idea (though they will largely be +ignored). +<p> + +Here is a brief list of the control info files supported by <prgn/dpkg/ +and a summary of what they're used for. +<p> + +<taglist> +<tag><tt/control/ +<item> + +This is the key description file used by <prgn/dpkg/. It specifies the +package's name and version, gives its description for the user, states +its relationships with other packages, and so forth. +See <ref id="controlfile">. +<p> + +It is usually generated automatically from information in the source +package by the <prgn/dpkg-gencontrol/ program, and with assistance +from <prgn/dpkg-shlibdeps/. See <ref id="sourcetools">. + +<tag><tt/postinst/, <tt/preinst/, <tt/postrm/, <tt/prerm/ +<item> + +These are exectuable files (usually scripts) which <prgn/dpkg/ runs +during installation, upgrade and removal of packages. They allow the +package to deal with matters which are particular to that package or +require more complicated processing than that provided by <prgn/dpkg/. +Details of when and how they are called are in +<ref id="maintainerscripts">. +<p> + +It is very important to make these scripts idempotent.<footnote>That +means that if it runs successfully or fails and then you call it again +it doesn't bomb out, but just ensures that everything is the way it +ought to be.</footnote> This is so that if an error occurs, the user +interrupts <prgn/dpkg/ or some other unforeseen circumstance happens you +don't leave the user with a badly-broken package. +<p> + +The maintainer scripts are guaranteed to run with a controlling +terminal and can interact with the user. If they need to prompt for +passwords, do full-screen interaction or something similar you should +do these things to and from <tt>/dev/tty</>, since <prgn/dpkg/ will at +some point redirect scripts' standard input and output so that it can +log the installation process. Likewise, because these scripts may be +executed with standard output redirected into a pipe for logging +purposes, Perl scripts should set unbuffered output by setting +<tt/$|=1/ so that the output is printed immediately rather than being +buffered. +<p> + +Each script should return a zero exit status for success, or a nonzero +one for failure. + +<tag><tt/conffiles/ +<item> + +This file contains a list of configuration files which are to be +handled automatically by <prgn/dpkg/ (see <ref id="conffiles">). Note +that not necessarily every configuration file should be listed here. + +<tag><tt/shlibs/ +<item> + +This file contains a list of the shared libraries supplied by the +package, with dependency details for each. This is used by +<prgn/dpkg-shlibdeps/ when it determines what dependencies are +required in a package control file. The <tt/shlibs/ file format is +described on <ref id="shlibs">. +<p> + +</taglist> + +<sect id="controlfile">The main control information file: <tt/control/ +<p> + +The most important control information file used by <prgn/dpkg/ when it +installs a package is <tt/control/. It contains all the package's +`vital statistics'. +<p> + +The binary package control files of packages built from Debian sources +are made by a special tool, <prgn/dpkg-gencontrol/, which reads +<tt>debian/control</> and <tt>debian/changelog</> to find the +information it needs. See <ref id="sourcepkg"> for more details. +<p> + +The fields in binary package control files are: +<list compact> + +<item><qref id="f-Package"><tt/Package/</> (mandatory) +<item><qref id="versions"><tt/Version/</> (mandatory) + +<item><qref id="f-Architecture"><tt/Architecture/</> +(mandatory)<footnote>This field should appear in all packages, though +<prgn/dpkg/ doesn't require it yet so that old packages can still be +installed.</footnote> + +<item><qref id="relationships"><tt/Depends/, <tt/Provides/ et al.</> +<item><qref id="f-Essential"><tt/Essential/</> +<item><qref id="f-Maintainer"><tt/Maintainer/</> +<item><qref id="f-classification"><tt/Section/, <tt/Priority/</> +<item><qref id="f-Source"><tt/Source/</> +<item><qref id="descriptions"><tt/Description/</> +<item><qref id="f-Installed-Size"><tt/Installed-Size/</> + +</list> +<p> + +A description of the syntax of control files and the purpose of these +fields is available in <ref id="controlfields">. + + +<chapt id="sourcepkg">Source packages +<p> + +The Debian binary packages in the distribution are generated from +Debian sources, which are in a special format to assist the easy and +automatic building of binaries. +<p> + +There was a previous version of the Debian source format, which is now +being phased out. Instructions for converting an old-style package +are given in the Debian policy manual. + +<sect id="sourcetools">Tools for processing source packages +<p> + +Various tools are provided for manipulating source packages; they pack +and unpack sources and help build of binary packages and help manage +the distribution of new versions. +<p> + +They are introduced and typical uses described here; see <manref +name=dpkg-source section=1> for full documentation about their +arguments and operation. +<p> + +For examples of how to construct a Debian source package, and how to +use those utilities that are used by Debian source packages, please +see the <prgn/hello/ example package. + +<sect1><prgn/dpkg-source/ - packs and unpacks Debian source packages +<p> + +This program is frequently used by hand, and is also called from +package-independent automated building scripts such as +<prgn/dpkg-buildpackage/. +<p> + +To unpack a package it is typically invoked with +<example> +dpkg-source -x <var>.../path/to/filename</>.dsc +</example> +with the <tt/<var/filename/.tar.gz/ and +<tt/<var/filename/.diff.gz/ (if applicable) in the same directory. It +unpacks into <tt/<var/package/-<var/version//, and if applicable +<tt/<var/package/-<var/version/.orig/, in the current directory. +<p> + +To create a packed source archive it is typically invoked: +<example> +dpkg-source -b <var/package/-<var/version/ +</example> +This will create the <tt/.dsc/, <tt/.tar.gz/ and <tt/.diff.gz/ (if +appropriate) in the current directory. <prgn/dpkg-source/ does not +clean the source tree first - this must be done separately if it is +required. +<p> + +See also <ref id="sourcearchives">. + + +<sect1><prgn/dpkg-buildpackage/ - overall package-building control +script +<p> + +<prgn/dpkg-buildpackage/ is a script which invokes <prgn/dpkg-source/, +the <tt>debian/rules</> targets <prgn/clean/, <prgn/build/ and +<prgn/binary/, <prgn/dpkg-genchanges/ and <prgn/pgp/ to build a signed +source and binary package upload. +<p> + +It is usually invoked by hand from the top level of the built or +unbuilt source directory. It may be invoked with no arguments; useful +arguments include: +<taglist compact> +<tag><tt/-uc/, <tt/-us/ +<item>Do not PGP-sign the <tt/.changes/ file or the source package +<tt/.dsc/ file, respectively. + +<tag><tt/-p<var/pgp-command// +<item>Invoke <var/pgp-command/ instead of finding <tt/pgp/ on the +<prgn/PATH/. <var/pgp-command/ must behave just like <prgn/pgp/. + +<tag><tt/-r<var/root-command// +<item>When root privilege is required, invoke the command +<var/root-command/. <var/root-command/ should invoke its first +argument as a command, from the <prgn/PATH/ if necessary, and pass its +second and subsequent arguments to the command it calls. If no +<var/root-command/ is supplied then <var/dpkg-buildpackage/ will take +no special action to gain root privilege, so that for most packages it +will have to be invoked as root to start with. + +<tag><tt/-b/, <tt/-B/ +<item>Two types of binary-only build and upload - see <manref +name=dpkg-source section=1>. +</taglist> + + +<sect1><prgn/dpkg-gencontrol/ - generates binary package control files +<p> + +This program is usually called from <tt>debian/rules</> (see <ref +id="sourcetree">) in the top level of the source tree. +<p> + +This is usually done just before the files and directories in the +temporary directory tree where the package is being built have their +permissions and ownerships set and the package is constructed using +<prgn/dpkg-deb/<footnote>This is so that the control file which is +produced has the right permissions</footnote>. +<p> + +<prgn/dpkg-gencontrol/ must be called after all the files which are to +go into the package have been placed in the temporary build directory, +so that its calculation of the installed size of a package is correct. +<p> + +It is also necessary for <prgn/dpkg-gencontrol/ to be run after +<prgn/dpkg-shlibdeps/ so that the variable substitutions created by +<prgn/dpkg-shlibdeps/ in <tt>debian/substvars</> are available. +<p> + +For a package which generates only one binary package, and which +builds it in <tt>debian/tmp</> relative to the top of the source +package, it is usually sufficient to call: +<example> +dpkg-gencontrol +</example> +<p> + +Sources which build several binaries will typically need something +like: +<example> +dpkg-gencontrol -Pdebian/tmp-<var/pkg/ -p<var/package/ +</example> +The <tt/-P/ tells <prgn/dpkg-gencontrol/ that the package is being +built in a non-default directory, and the <tt/-p/ tells it which +package's control file should be generated. +<p> + +<prgn/dpkg-gencontrol/ also adds information to the list of files in +<tt>debian/files</>, for the benefit of (for example) a future +invocation of <prgn/dpkg-genchanges/. + + +<sect1><prgn/dpkg-shlibdeps/ - calculates shared library dependencies +<p> + +This program is usually called from <tt>debian/rules</> just before +<prgn/dpkg-gencontrol/ (see <ref id="sourcetree">), in the top level +of the source tree. +<p> + +Its arguments are executables<footnote>They may be specified either +in the locations in the source tree where they are created or in the +locations in the temporary build tree where they are installed prior +to binary package creation.</footnote> for which shared library +dependencies should be included in the binary package's control file. +<p> + +If some of the executable(s) shared libraries should only warrant a +<tt/Recommends/ or <tt/Suggests/, or if some warrant a +<tt/Pre-Depends/, this can be achieved by using the +<tt/-d<var/dependency-field// option before those executable(s). +(Each <tt/-d/ option takes effect until the next <tt/-d/.) +<p> + +<prgn/dpkg-shlibdeps/ does not directly cause the output control file +to be modified. Instead by default it adds to the +<tt>debian/substvars</> file variable settings like +<tt/shlibs:Depends/. These variable settings must be referenced in +dependency fields in the appropriate per-binary-package sections of +the source control file. +<p> + +For example, the <prgn/procps/ package generates two kinds of +binaries, simple C binaries like <prgn/ps/ which require a +predependency and full-screen ncurses binaries like <prgn/top/ which +require only a recommendation. It can say in its <tt>debian/rules</>: +<example> +dpkg-shlibdeps -dPre-Depends ps -dRecommends top +</example> +and then in its main control file <tt>debian/control</>: +<example> +<var/.../ +Package: procps +Pre-Depends: ${shlibs:Pre-Depends} +Recommends: ${shlibs:Recommends} +<var/.../ +</example> +<p> + +Sources which produce several binary packages with different shared +library dependency requirements can use the <tt/-p<var/varnameprefix// +option to override the default <tt/shlib:/ prefix (one invocation of +<prgn/dpkg-shlibdeps/ per setting of this option). They can thus +produce several sets of dependency variables, each of the form +<tt/<var/varnameprefix/:<var/dependencyfield//, which can be referred +to in the appropriate parts of the binary package control files. + + +<sect1><prgn/dpkg-distaddfile/ - adds a file to <tt>debian/files</> +<p> + +Some packages' uploads need to include files other than the source and +binary package files. +<p> + +<prgn/dpkg-distaddfile/ adds a file to the <tt>debian/files</> file so +that it will be included in the <tt/.changes/ file when +<prgn/dpkg-genchanges/ is run. +<p> + +It is usually invoked from the <prgn/binary/ target of +<tt>debian/rules</>: +<example> +dpkg-distaddfile <var/filename/ <var/section/ <var/priority/ +</example> +The <var/filename/ is relative to the directory where +<prgn/dpkg-genchanges/ will expect to find it - this is usually the +directory above the top level of the source tree. The +<tt>debian/rules</> target should put the file there just before or +just after calling <prgn/dpkg-distaddfile/. +<p> + +The <var/section/ and <var/priority/ are passed unchanged into the +resulting <tt/.changes/ file. See <ref id="f-classification">. + + +<sect1><prgn/dpkg-genchanges/ - generates a <tt/.changes/ upload +control file +<p> + +This program is usually called by package-independent automatic +building scripts such as <prgn/dpkg-buildpackage/, but it may also be +called by hand. +<p> + +It is usually called in the top level of a built source tree, and when +invoked with no arguments will print out a straightforward +<tt/.changes/ file based on the information in the source package's +changelog and control file and the binary and source packages which +should have been built. + + +<sect1><prgn/dpkg-parsechangelog/ - produces parsed representation of +a changelog +<p> + +This program is used internally by <prgn/dpkg-source/ et al. It may +also occasionally be useful in <tt>debian/rules</> and elsewhere. It +parses a changelog, <tt>debian/changelog</> by default, and prints a +control-file format representation of the information in it to +standard output. + +<sect id="sourcetree">The Debianised source tree +<p> + +The source archive scheme described later is intended to allow a +Debianised source tree with some associated control information to be +reproduced and transported easily. The Debianised source tree is a +version of the original program with certain files added for the +benefit of the Debianisation process, and with any other changes +required made to the rest of the source code and installation scripts. +<p> + +The extra files created for Debian are in the subdirectory <tt/debian/ +of the top level of the Debianised source tree. They are described +below. + +<sect1><tt>debian/rules</tt> - the main building script +<p> + +This file is an executable makefile, and contains the package-specific +recipies for compiling the package and building binary package(s) out +of the source. +<p> + +It must start with the line <tt>#!/usr/bin/make -f</tt>, so that it +can be invoked by saying its name rather than invoking <prgn/make/ +explicitly. +<p> + +The targets which are required to be present are: + +<taglist> +<tag/<tt/build// +<item> + +This should perform all non-interactive configuration and compilation +of the package. If a package has an interactive pre-build +configuration routine, the Debianised source package should be built +after this has taken place, so that it can be built without rerunning +the configuration. +<p> + +For some packages, notably ones where the same source tree is compiled +in different ways to produce two binary packages, the <prgn/build/ +target does not make much sense. For these packages it is good enough +to provide two (or more) targets (<tt/build-a/ and <tt/build-b/ or +whatever) for each of the ways of building the package, and a +<prgn/build/ target that does nothing. The <prgn/binary/ target will have +to build the package in each of the possible ways and make the binary +package out of each. +<p> + +The <prgn/build/ target must not do anything that might require root +privilege. +<p> + +The <prgn/build/ target may need to run <prgn/clean/ first - see below. +<p> + +When a package has a configuration routine that takes a long time, or +when the makefiles are poorly designed, or when <prgn/build/ needs to +run <prgn/clean/ first, it is a good idea to <tt/touch build/ when the +build process is complete. This will ensure that if <tt>debian/rules +build</tt> is run again it will not rebuild the whole program. + +<tag/<tt/binary/, <tt/binary-arch/, <tt/binary-indep/ +<item> + +The <prgn/binary/ target should be all that is necessary for the user +to build the binary package. It is split into two parts: +<prgn/binary-arch/ builds the packages' output files which are +specific to a particular architecture, and <prgn/binary-indep/ +builds those which are not. +<p> + +<prgn/binary/ should usually be a target with no commands which simply +depends on <prgn/binary-arch/ and <prgn/binary-indep/. +<p> + +Both <prgn/binary-*/ targets should depend on the <prgn/build/ target, +above, so that the package is built if it has not been already. It +should then create the relevant binary package(s), using +<prgn/dpkg-gencontrol/ to make their control files and <prgn/dpkg-deb/ +to build them and place them in the parent of the top level directory. +<p> + +If one of the <prgn/binary-*/ targets has nothing to do (this will be +always be the case if the source generates only a single binary +package, whether architecture-dependent or not) it <em/must/ still +exist, but should always succeed. +<p> + +<ref id="binarypkg"> describes how to construct binary packages. +<p> + +The <prgn/binary/ targets must be invoked as root. + +<tag/<tt/clean// +<item> + +This should undo any effects that the <prgn/build/ and <prgn/binary/ +targets may have had, except that it should leave alone any output +files created in the parent directory by a run of <prgn/binary/. +<p> + +If a <prgn/build/ file is touched at the end of the <prgn/build/ target, +as suggested above, it must be removed as the first thing that +<prgn/clean/ does, so that running <prgn/build/ again after an interrupted +<prgn/clean/ doesn't think that everything is already done. +<p> + +The <prgn/clean/ target must be invoked as root if <prgn/binary/ has +been invoked since the last <prgn/clean/, or if <prgn/build/ has been +invoked as root (since <prgn/build/ may create directories, for +example). + +<tag/<tt/get-orig-source/ (optional)/ +<item> + +This target fetches the most recent version of the original source +package from a canonical archive site (via FTP or WWW, for example), +does any necessary rearrangement to turn it into the original source +tarfile format described below, and leaves it in the current directory. +<p> + +This target may be invoked in any directory, and should take care to +clean up any temporary files it may have left. +<p> + +This target is optional, but providing it if possible is a good idea. + +</taglist> + +The <prgn/build/, <prgn/binary/ and <prgn/clean/ targets must be +invoked with a current directory of the package's top-level +directory. + +<p> + +Additional targets may exist in <tt>debian/rules</tt>, either as +published or undocumented interfaces or for the package's internal +use. + + +<sect1><tt>debian/control</tt> +<p> + +This file contains version-independent details about the source +package and about the binary packages it creates. +<p> + +It is a series of sets of control fields, each syntactically similar +to a binary package control file. The sets are separated by one or +more blank lines. The first set is information about the source +package in general; each subsequent set describes one binary package +that the source tree builds. +<p> + +The syntax and semantics of the fields are described below in +<ref id="controlfields">. +<p> + +The general (binary-package-independent) fields are: +<list compact> +<item><qref id="f-Source"><tt/Source/</> (mandatory) +<item><qref id="f-Maintainer"><tt/Maintainer/</> +<item><qref id="f-classification"><tt/Section/ and <tt/Priority/</> +(classification, mandatory) +<item><qref id="f-Standards-Version"><tt/Standards-Version/</> +</list> +<p> + +The per-binary-package fields are: +<list compact> +<item><qref id="f-Package"><tt/Package/</> (mandatory) +<item><qref id="f-Architecture"><tt/Architecture/</> (mandatory) +<item><qref id="descriptions"><tt/Description/</> +<item><qref id="f-classification"><tt/Section/ and <tt/Priority/</> (classification) +<item><qref id="f-Essential"><tt/Essential/</> +<item><qref id="relationships"><tt/Depends/ et al.</> (package interrelationships) +</list> +<p> + +These fields are used by <prgn/dpkg-gencontrol/ to generate control +files for binary packages (see below), by <prgn/dpkg-genchanges/ to +generate the <tt/.changes/ file to accompany the upload, and by +<prgn/dpkg-source/ when it creates the <tt/.dsc/ source control file as +part of a source archive. +<p> + +The fields here may contain variable references - their values will be +substituted by <prgn/dpkg-gencontrol/, <prgn/dpkg-genchanges/ or +<prgn/dpkg-source/ when they generate output control files. See <ref +id="srcsubstvars"> for details. +<p> + +<sect2>User-defined fields +<p> + +Additional user-defined fields may be added to the source package +control file. Such fields will be ignored, and not copied to (for +example) binary or source package control files or upload control +files. +<p> + +If you wish to add additional unsupported fields to these output files +you should use the mechanism described here. +<p> + +Fields in the main source control information file with names starting +<tt/X/, followed by one or more of the letters <tt/BCS/ and a hyphen +<tt/-/, will be copied to the output files. Only the part of the +field name after the hyphen will be used in the output file. Where +the letter <tt/B/ is used the field will appear in binary package +control files, where the letter <tt/S/ is used in source package +control files and where <tt/C/ is used in upload control +(<tt/.changes/) files. +<p> + +For example, if the main source information control file contains the +field +<example> +XBS-Comment: I stand between the candle and the star. +</example> +then the binary and source package control files will contain the +field +<example> +Comment: I stand between the candle and the star. +</example> + +<sect1 id="dpkgchangelog"><tt>debian/changelog</> +<p> + +This file records the changes to the Debian-specific parts of the +package<footnote>Though there is nothing stopping an author who is +also the Debian maintainer from using it for all their changes, it +will have to be renamed if the Debian and upstream maintainers become +different people.</footnote>. +<p> + +It has a special format which allows the package building tools to +discover which version of the package is being built and find out +other release-specific information. +<p> + +That format is a series of entries like this: +<p> +<example> +<var/package/ (<var/version/) <var/distribution(s)/; urgency=<var/urgency/ + + * <var/change details/ + <var/more change details/ + * <var/even more change details/ + + -- <var/maintainer name and email address/ <var/date/ +</example> +<p> + +<var/package/ and <var/version/ are the source package name and +version number. +<p> +<var/distribution(s)/ lists the distributions where +this version should be installed when it is uploaded - it is copied to +the <tt/Distribution/ field in the <tt/.changes/ file. See <ref +id="f-Distribution">. +<p> + +<var/urgency/ is the value for the <tt/Urgency/ field in the +<tt/.changes/ file for the upload. See <ref id="f-Urgency">. It is +not possible to specify an urgency containing commas; commas are used +to separate <tt/<var/keyword/=<var/value// settings in the <prgn/dpkg/ +changelog format (though there is currently only one useful +<var/keyword/, <tt/urgency/). +<p> + +The change details may in fact be any series of lines starting with at +least two spaces, but conventionally each change starts with an +asterisk and a separating space and continuation lines are indented so +as to bring them in line with the start of the text above. Blank +lines may be used here to separate groups of changes, if desired. +<p> + +The maintainer name and email address should <em/not/ necessarily be +those of the usual package maintainer. They should be the details of +the person doing <em/this/ version. The information here will be +copied to the <tt/.changes/ file, and then later used to send an +acknowledgement when the upload has been installed. +<p> + +The <var/date/ should be in RFC822 format<footnote>This is generated +by the <prgn/822-date/ program.</footnote>; it should include the +timezone specified numerically, with the timezone name or abbreviation +optionally present as a comment. +<p> + +The first `title' line with the package name should start at the left +hand margin; the `trailer' line with the maintainer and date details +should be preceded by exactly one space. The maintainer details and +the date must be separated by exactly two spaces. +<p> + +An Emacs mode for editing this format is available: it is called +<tt/debian-changelog-mode/. You can have this mode selected +automatically when you edit a Debian changelog by adding a local +variables clause to the end of the changelog. + +<sect2>Defining alternative changelog formats +<p> + +It is possible to use a different format to the standard one, by +providing a parser for the format you wish to use. +<p> + +In order to have <tt/dpkg-parsechangelog/ run your parser, you must +include a line within the last 40 lines of your file matching the Perl +regular expression: +<tt>\schangelog-format:\s+([0-9a-z]+)\W</tt> +The part in parentheses should be the name of the format. For +example, you might say: +<example> +@@@ changelog-format: joebloggs @@@ +</example> +Changelog format names are non-empty strings of alphanumerics. +<p> + +If such a line exists then <tt/dpkg-parsechangelog/ will look for the +parser as <tt>/usr/lib/dpkg/parsechangelog/<var/format-name/</> or +<tt>/usr/local/lib/dpkg/parsechangelog/<var/format-name/</>; it is an +error for it not to find it, or for it not to be an executable +program. The default changelog format is <tt/dpkg/, and a parser for +it is provided with the <tt/dpkg/ package. +<p> + +The parser will be invoked with the changelog open on standard input +at the start of the file. It should read the file (it may seek if it +wishes) to determine the information required and return the parsed +information to standard output in the form of a series of control +fields in the standard format. By default it should return +information about only the most recent version in the changelog; it +should accept a <tt/-v<var/version// option to return changes +information from all versions present <em/strictly after/ +<var/version/, and it should then be an error for <var/version/ not to +be present in the changelog. +<p> + +The fields are: +<list compact> +<item><qref id="f-Source"><tt/Source/</> +<item><qref id="versions"><tt/Version/</> (mandatory) +<item><qref id="f-Distribution"><tt/Distribution/</> (mandatory) +<item><qref id="f-Urgency"><tt/Urgency/</> (mandatory) +<item><qref id="f-Maintainer"><tt/Maintainer/</> (mandatory) +<item><qref id="f-Date"><tt/Date/</> +<item><qref id="f-Changes"><tt/Changes/</> (mandatory) +</list> +<p> + +If several versions are being returned (due to the use of <tt/-v/), +the urgency value should be of the highest urgency code listed at the +start of any of the versions requested followed by the concatenated +(space-separated) comments from all the versions requested; the +maintainer, version, distribution and date should always be from the +most recent version. +<p> + +For the format of the <tt/Changes/ field see <ref id="f-Changes">. +<p> + +If the changelog format which is being parsed always or almost always +leaves a blank line between individual change notes these blank lines +should be stripped out, so as to make the resulting output compact. +<p> + +If the changelog format does not contain date or package name +information this information should be omitted from the output. The +parser should not attempt to synthesise it or find it from other +sources. +<p> + +If the changelog does not have the expected format the parser should +exit with a nonzero exit status, rather than trying to muddle through +and possibly generating incorrect output. +<p> + +A changelog parser may not interact with the user at all. + +<sect1 id="srcsubstvars"><tt>debian/substvars</> and variable substitutions +<p> + +When <prgn/dpkg-gencontrol/, <prgn/dpkg-genchanges/ and +<prgn/dpkg-source/ generate control files they do variable +substitutions on their output just before writing it. Variable +substitutions have the form <tt/${<var/variable-name/}/. The optional +file <tt>debian/substvars</> contains variable substitutions to be +used; variables can also be set directly from <tt>debian/rules</> +using the <tt/-V/ option to the source packaging commands, and certain +predefined variables are available. +<p> + +The is usually generated and modified dynamically by +<tt>debian/rules</> targets; in this case it must be removed by the +<prgn/clean/ target. +<p> + + + +See <manref name=dpkg-source section=1> for full details about source +variable substitutions, including the format of +<tt>debian/substvars</>. + +<sect1><tt>debian/files</> +<p> + +This file is not a permanent part of the source tree; it is used while +building packages to record which files are being generated. +<prgn/dpkg-genchanges/ uses it when it generates a <tt/.changes/ file. +<p> + +It should not exist in a shipped source package, and so it (and any +backup files or temporary files such as +<tt/files.new/<footnote><tt/files.new/ is used as a temporary file by +<prgn/dpkg-gencontrol/ and <prgn/dpkg-distaddfile/ - they write a new +version of <tt/files/ here before renaming it, to avoid leaving a +corrupted copy if an error occurs</footnote>) should be removed by the +<prgn/clean/ target. It may also be wise to ensure a fresh start by +emptying or removing it at the start of the <prgn/binary/ target. +<p> + +<prgn/dpkg-gencontrol/ adds an entry to this file for the <tt/.deb/ +file that will be created by <prgn/dpkg-deb/ from the control file +that it generates, so for most packages all that needs to be done with +this file is to delete it in <prgn/clean/. +<p> + +If a package upload includes files besides the source package and any +binary packages whose control files were made with +<prgn/dpkg-gencontrol/ then they should be placed in the parent of the +package's top-level directory and <prgn/dpkg-distaddfile/ should be +called to add the file to the list in <tt>debian/files</>. + +<sect1><tt>debian/tmp</> +<p> + +This is the canonical temporary location for the construction of +binary packages by the <prgn/binary/ target. The directory <tt/tmp/ +serves as the root of the filesystem tree as it is being constructed +(for example, by using the package's upstream makefiles install +targets and redirecting the output there), and it also contains the +<tt/DEBIAN/ subdirectory. See <ref id="bincreating">. +<p> + +If several binary packages are generated from the same source tree it +is usual to use several <tt>debian/tmp<var/something/</> directories, +for example <tt/tmp-a/ or <tt/tmp-doc/. +<p> + +Whatever <tt>tmp</> directories are created and used by <prgn/binary/ +must of course be removed by the <prgn/clean/ target. + + +<sect id="sourcearchives">Source packages as archives +<p> + +As it exists on the FTP site, a Debian source package consists of +three related files. You must have the right versions of all three to +be able to use them. +<p> + +<taglist> +<tag/Debian source control file - <tt/.dsc// +<item> + +This file contains a series of fields, identified and separated just +like the fields in the control file of a binary package. The fields +are listed below; their syntax is described above, in +<ref id="controlfields">. +<list compact> +<item><qref id="f-Source"><tt/Source/</> +<item><qref id="versions"><tt/Version/</> +<item><qref id="f-Maintainer"><tt/Maintainer/</> +<item><qref id="f-Binary"><tt/Binary/</> +<item><qref id="f-Architecture"><tt/Architecture/</> +<item><qref id="f-Standards-Version"><tt/Standards-Version/</> +<item><qref id="f-Files"><tt/Files/</> +</list> +<p> + +The source package control file is generated by <prgn/dpkg-source/ +when it builds the source archive, from other files in the source +package, described above. When unpacking it is checked against the +files and directories in the other parts of the source package, as +described below. + +<tag/Original source archive - <tt/<var/package/_<var/upstream-version/.orig.tar.gz// +<item> + +This is a compressed (with <tt/gzip -9/) <prgn/tar/ file containing +the source code from the upstream authors of the program. The tarfile +unpacks into a directory +<tt/<var/package/-<var/upstream-version/.orig/, and does not contain +files anywhere other than in there or in its subdirectories. + +<tag/Debianisation diff - <tt/<var/package/_<var/upstream_version-revision/.diff.gz// +<item> + +This is a unified context diff (<tt/diff -u/) giving the changes which +are required to turn the original source into the Debian source. +These changes may only include editing and creating plain files. The +permissions of files, the targets of symbolic links and the +characteristics of special files or pipes may not be changed and no +files may be removed or renamed. +<p> + +All the directories in the diff must exist, except the <tt/debian/ +subdirectory of the top of the source tree, which will be created by +<prgn/dpkg-source/ if necessary when unpacking. +<p> + +The <prgn/dpkg-source/ program will automatically make the +<tt>debian/rules</tt> file executable (see below). + +</taglist> +<p> + +If there is no original source code - for example, if the package is +specially prepared for Debian or the Debian maintainer is the same as +the upstream maintainer - the format is slightly different: then there +is no diff, and the tarfile is named +<tt/<var/package/_<var/version/.tar.gz</> and contains a directory +<tt/<var/package/-<var/version/</>. + +<sect>Unpacking a Debian source package without <prgn/dpkg-source/ +<p> + +<tt/dpkg-source -x/ is the recommended way to unpack a Debian source +package. However, if it is not available it is possible to unpack a +Debian source archive as follows: + +<enumlist compact> +<item>Untar the tarfile, which will create a <tt/.orig/ directory. +<item>Rename the <tt/.orig/ directory to +<tt/<var/package/-<var/version//. +<item>Create the subdirectory <tt/debian/ at the top of the source +tree. +<item>Apply the diff using <tt/patch -p0/. +<item>Untar the tarfile again if you want a copy of the original +source code alongside the Debianised version. +</enumlist> +<p> + +It is not possible to generate a valid Debian source archive without +using <prgn/dpkg-source/. In particular, attempting to use +<prgn/diff/ directly to generate the <tt/.diff.gz/ file will not work. + +<sect1>Restrictions on objects in source packages +<p> + +The source package may not contain any hard links<footnote>This is not +currently detected when building source packages, but only when +extracting them.</footnote><footnote>Hard links may be permitted at +some point in the future, but would require a fair amount of +work.</footnote>, device special files, sockets or setuid or setgid +files.<footnote>Setgid directories are allowed.</footnote> +<p> + +The source packaging tools manage the changes between the original and +Debianised source using <prgn/diff/ and <prgn/patch/. Turning the +original source tree as included in the <tt/.orig.tar.gz/ into the +debianised source must not involve any changes which cannot be handled +by these tools. Problematic changes which cause <prgn/dpkg-source/ to +halt with an error when building the source package are: +<list compact> +<item>Adding or removing symbolic links, sockets or pipes. +<item>Changing the targets of symbolic links. +<item>Creating directories, other than <tt/debian/. +<item>Changes to the contents of binary files. +</list> +Changes which cause <prgn/dpkg-source/ to print a warning but continue +anyway are: +<list compact> +<item>Removing files, directories or symlinks. <footnote>Renaming a +file is not treated specially - it is seen as the removal of the old +file (which generates a warning, but is otherwise ignored), and the +creation of the new one.</footnote> +<item>Changed text files which are missing the usual final newline +(either in the original or the modified source tree). +</list> +Changes which are not represented, but which are not detected by +<prgn/dpkg-source/, are: +<list compact> +<item>Changing the permissions of files (other than +<tt>debian/rules</>) and directories. +</list> +<p> + +The <tt/debian/ directory and <tt>debian/rules</> are handled +specially by <prgn/dpkg-source/ - before applying the changes it will +create the <tt/debian/ directory, and afterwards it will make +<tt>debian/rules</> world-exectuable. + +<chapt id="controlfields">Control files and their fields +<p> + +Many of the tools in the <prgn/dpkg/ suite manipulate data in a common +format, known as control files. Binary and source packages have +control data as do the <tt/.changes/ files which control the +installation of uploaded files, and <prgn/dpkg/'s internal databases +are in a similar format. + +<sect>Syntax of control files +<p> + +A file consists of one or more paragraphs of fields. The paragraphs +are separated by blank lines. Some control files only allow one +paragraph; others allow several, in which case each paragraph often +refers to a different package. +<p> + +Each paragraph is a series of fields and values; each field consists +of a name, followed by a colon and the value. It ends at the end of +the line. Horizontal whitespace (spaces and tabs) may occur before or +after the value and is ignored there; it is conventional to put a +single space after the colon. +<p> + +Some fields' values may span several lines; in this case each +continuation line <em/must/ start with a space or tab. Any trailing +spaces or tabs at the end of individual lines of a field value are +ignored. +<p> + +Except where otherwise stated only a single line of data is allowed +and whitespace is not significant in a field body. Whitespace may +never appear inside names (of packages, architectures, files or +anything else), version numbers or in between the characters of +multi-character version relationships. +<p> + +Field names are not case-sensitive, but it is usual to capitalise the +fields using mixed case as shown below. +<p> + +Blank lines, or lines consisting only of spaces and tabs, are not +allowed within field values or between fields - that would mean a new +paragraph. +<p> + +It is important to note that there are several fields which are +optional as far as <prgn/dpkg/ and the related tools are concerned, +but which must appear in every Debian package, or whose omission may +cause problems. When writing the control files for Debian packages +you <em/must/ read the Debian policy manual in conjuction with the +details below and the list of fields for the particular file. + +<sect>List of fields + +<sect1 id="f-Package"><tt/Package/ +<p> + +The name of the binary package. Package names consist of the +alphanumerics and <tt/+/ <tt/-/ <tt/./ (plus, minus and full +stop).<footnote>The characters <tt/@/ <tt/:/ <tt/=/ <tt/%/ <tt/_/ (at, +colon, equals, percent and underscore) used to be legal and are still +accepted when found in a package file, but may not be used in new +packages</footnote> +<p> + +They must be at least two characters and must start with an +alphanumeric. In current versions of dpkg they are sort of +case-sensitive<footnote>This is a bug.</footnote>; use lowercase +package names unless the package you're building (or referring to, in +other fields) is already using uppercase. + +<sect1 id="f-Version"><tt/Version/ +<p> + +This lists the source or binary package's version number - see <ref +id="versions">. + +<sect1 id="f-Architecture"><tt/Architecture/ +<p> + +This is the architecture string; it is a single word for the CPU +architecture. +<p> + +<prgn/dpkg/ will check the declared architecture of a binary package +against its own compiled-in value before it installs it. +<p> + +The special value <tt/all/ indicates that the package is +architecture-independent. +<p> + +In the main <tt>debian/control</> file in the source package, or in +the source package control file <tt/.dsc/, a list of architectures +(separated by spaces) is also allowed, as is the special value +<tt/any/. A list indicates that the source will build an +architecture-dependent package, and will only work correctly on the +listed architectures. <tt/any/ indicates that though the source +package isn't dependent on any particular architecture and should +compile fine on any one, the binary package(s) produced are not +architecture-independent but will instead be specific to whatever the +current build architecture is. +<p> + +In a <tt/.changes/ file the <tt/Architecture/ field lists the +architecture(s) of the package(s) currently being uploaded. This will +be a list; if the source for the package is being uploaded too the +special entry <tt/source/ is also present. +<p> + +The current build architecture can be determined using <tt/dpkg +--print-architecture/.<footnote>This actually invokes +<example> +gcc --print-libgcc-file-name +</example> +and parses and decomposes the output and looks the CPU type from the +GCC configuration in a table in <prgn/dpkg/. This is so that it will +work if you're cross-compiling. +</footnote> +This value is automatically used by <prgn/dpkg-gencontrol/ when +building the control file for a binary package for which the source +control information doesn't specify architecture <tt/all/. +<p> + +There is a separate option, <tt/--print-installation-architecture/, +for finding out what architecture <prgn/dpkg/ is willing to install. +This information is also in the output of <tt/dpkg --version/. + +<sect1 id="f-Maintainer"><tt/Maintainer/ +<p> + +The package maintainer's name and email address. The name should come +first, then the email address inside angle brackets <tt/<>/ (in +RFC822 format). +<p> + +If the maintainer's name contains a full stop then the whole field +will not work directly as an email address due to a misfeature in the +syntax specified in RFC822; a program using this field as an address +must check for this and correct the problem if necessary (for example +by putting the name in round brackets and moving it to the end, and +bringing the email address forward). +<p> + +In a <tt/.changes/ file or parsed changelog data this contains the +name and email address of the person responsible for the particular +version in question - this may not be the package's usual maintainer. +<p> + +This field is usually optional in as far as the <prgn/dpkg/ are +concerned, but its absence when building packages usually generates a +warning. + +<sect1 id="f-Source"><tt/Source/ +<p> + +This field identifies the source package name. +<p> + +In a main source control information or a <tt/.changes/ or <tt/.dsc/ +file or parsed changelog data this may contain only the name of the +source package. +<p> + +In the control file of a binary package (or in a <tt/Packages/ file) +it may be followed by a version number in parentheses.<footnote>It is +usual to leave a space after the package name if a version number is +specified.</footnote> This version number may be omitted (and is, by +<prgn/dpkg-gencontrol/) if it has the same value as the <tt/Version/ +field of the binary package in question. The field itself may be +omitted from a binary package control file when the source package has +the same name and version as the binary package. + +<sect1>Package interrelationship fields: +<tt/Depends/, <tt/Pre-Depends/, <tt/Recommends/ +<tt/Suggests/, <tt/Conflicts/, <tt/Provides/, <tt/Replaces/ +<p> + +These fields describe the package's relationships with other packages. +Their syntax and semantics are described in <ref id="relationships">. + +<sect1 id="f-Description"><tt/Description/ +<p> + +In a binary package <tt/Packages/ file or main source control file +this field contains a description of the binary package, in a special +format. See <ref id="descriptions"> for details. +<p> + +In a <tt/.changes/ file it contains a summary of the descriptions for +the packages being uploaded. The part of the field before the first +newline is empty; thereafter each line has the name of a binary +package and the summary description line from that binary package. +Each line is indented by one space. + +<sect1 id="f-Essential"><tt/Essential/ +<p> + +This is a boolean field which may occur only in the control file of a +binary package (or in the <tt/Packages/ file) or in a per-package +fields paragraph of a main source control data file. +<p> + +If set to <tt/yes/ then <prgn/dpkg/ and <prgn/dselect/ will refuse to +remove the package (though it can be upgraded and/or replaced). The +other possible value is <tt/no/, which is the same as not having the +field at all. + +<sect1 id="f-classification"><tt/Section/ and <tt/Priority/ +<p> + +These two fields classify the package. The <tt/Priority/ represents +how important that it is that the user have it installed; the +<tt/Section/ represents an application area into which the package has +been classified. +<p> + +When they appear in the <tt>debian/control</> file these fields give +values for the section and priority subfields of the <tt/Files/ field +of the <tt/.changes/ file, and give defaults for the section and +priority of the binary packages. +<p> + +The section and priority are represented, though not as separate +fields, in the information for each file in the <qref +id="f-Files"><tt/Files/</> field of a <tt/.changes/ file. The +section value in a <tt/.changes/ file is used to decide where to +install a package in the FTP archive. +<p> + +These fields are not used by by <prgn/dpkg/ proper, but by +<prgn/dselect/ when it sorts packages and selects defaults. See the +Debian policy manual for the priorities in use and the criteria for +selecting the priority for a Debian package, and look at the Debian +FTP archive for a list of currently in-use priorities. +<p> + +These fields may appear in binary package control files, in which case +they provide a default value in case the <tt/Packages/ files are +missing the information. <prgn/dpkg/ and <prgn/dselect/ will only use +the value from a <tt/.deb/ file if they have no other information; a +value listed in a <tt/Packages/ file will always take precedence. By +default <prgn/dpkg-genchanges/ does not include the section and +priority in the control file of a binary package - use the <tt/-isp/, +<tt/-is/ or <tt/-ip/ options to achieve this effect. + +<sect1 id="f-Binary"><tt/Binary/ +<p> + +This field is a list of binary packages. +<p> + +When it appears in the <tt/.dsc/ file it is the list of binary +packages which a source package can produce. It does not necessarily +produce all of these binary packages for every architecture. The +source control file doesn't contain details of which architectures are +appropriate for which of the binary packages. +<p> + +When it appears in a <tt/.changes/ file it lists the names of the +binary packages actually being uploaded. +<p> + +The syntax is a list of binary packages separated by +commas.<footnote>A space after each comma is conventional.</footnote> +Currently the packages must be separated using only spaces in the +<tt/.changes/ file. + +<sect1 id="f-Installed-Size"><tt/Installed-Size/ +<p> + +This field appears in the control files of binary packages, and in the +<tt/Packages/ files. It gives the total amount of disk space +required to install the named package. +<p> + +The disk space is represented in kilobytes as a simple decimal number. + +<sect1 id="f-Files"><tt/Files/ +<p> + +This field contains a list of files with information about each one. +The exact information and syntax varies with the context. In all +cases the the part of the field contents on the same line as the field +name is empty. The remainder of the field is one line per file, each +line being indented by one space and containing a number of sub-fields +separated by spaces. +<p> + +In the <tt/.dsc/ (Debian source control) file each line contains the +MD5 checksum, size and filename of the tarfile and (if applicable) +diff file which make up the remainder of the source +package.<footnote>That is, the parts which are not the +<tt/.dsc/.</footnote> The exact forms of the filenames are described +in <ref id="sourcearchives">. +<p> + +In the <tt/.changes/ file this contains one line per file being +uploaded. Each line contains the MD5 checksum, size, section and +priority and the filename. The section and priority are the values of +the corresponding fields in the main source control file - see <ref +id="f-classification">. If no section or priority is specified then +<tt/-/ should be used, though section and priority values must be +specified for new packages to be installed properly. +<p> + +The special value <tt/byhand/ for the section in a <tt/.changes/ file +indicates that the file in question is not an ordinary package file +and must by installed by hand by the distribution maintainers. If the +section is <tt/byhand/ the priority should be <tt/-/. +<p> + +If a new Debian revision of a package is being shipped and no new +original source archive is being distributed the <tt/.dsc/ must still +contain the <tt/Files/ field entry for the original source archive +<tt/<var/package/-<var/upstream-version/.orig.tar.gz/, but the +<tt/.changes/ file should leave it out. In this case the original +source archive on the distribution site must match exactly, +byte-for-byte, the original source archive which was used to generate +the <tt/.dsc/ file and diff which are being uploaded. + + +<sect1 id="f-Standards-Version"><tt/Standards-Version/ +<p> + +The most recent version of the standards (the <prgn/dpkg/ programmers' +and policy manuals and associated texts) with which the package +complies. This is updated manually when editing the source package to +conform to newer standards; it can sometimes be used to tell when a +package needs attention. +<p> + +Its format is the same as that of a version number except that no +epoch or Debian revision is allowed - see <ref id="versions">. + + +<sect1 id="f-Distribution"><tt/Distribution/ +<p> + +In a <tt/.changes/ file or parsed changelog output this contains the +(space-separated) name(s) of the distribution(s) where this version of +the package should be or was installed. Distribution names follow the +rules for package names. (See <ref id="f-Package">). +<p> + +Current distribution values are: +<taglist> +<tag/<em/stable// +<item> +This is the current `released' version of Debian GNU/Linux. A new +version is released approximately every 3 months after the +<em/development/ code has been <em/frozen/ for a month of testing. +Once the distribution is <em/stable/ only major bug fixes are +allowed. When changes are made to this distribution, the minor version +number is increased (for example: 1.2 becomes 1.2.1 then 1.2.2, etc). + +<tag/<em/unstable// +<item> +This distribution value refers to the <em/developmental/ part of the Debian +distribution tree. New packages, new upstream versions of packages and +bug fixes go into the <em/unstable/ directory tree. Download +from this distribution at your own risk. + +<tag/<em/contrib// +<item> +The packages with this distribution value do not meet the criteria for +inclusion in the main Debian distribution as defined by the Policy +Manual, but meet the criteria for the <em/contrib/ Distribution. There +is currently no distinction between stable and unstable packages in +the <em/contrib/ or <em/non-free/ distributions. Use your best +judgement in downloading from this Distribution. + +<tag/<em/non-free// +<item> +Like the packages in the <em/contrib/ seciton, the packages in +<em/non-free/ do not meet the criteria for inclusion in the main +Debian distribution as defined by the Policy Manual. Again, use your +best judgement in downloading from this Distribution. + +<tag/<em/experimental// +<item> +The packages with this distribution value are deemed by their +maintainers to be high risk. Oftentimes they represent early beta or +developmental packages from various sources that the maintainers want +people to try, but are not ready to be a part of the other parts of +the Debian distribution tree. Download at your own risk. + +<tag/<em/frozen// +<item> +From time to time, (currently, every 3 months) the <em/unstable/ +distribution enters a state of `code-freeze' in anticipation of +release as a <em/stable/ version. During this period of testing +(usually 4 weeks) only fixes for existing or newly-discovered bugs +will be allowed. + +</taglist> +<p> +You should list <em/all/ distributions that the package should be +installed into. Except in unusual circumstances, installations to +<em/stable/ should also go into <em/frozen/ (if it exists) and +<em/unstable/. Likewise, installations into <em/frozen/ should also go +into <em/unstable/. + +<sect1 id="f-Urgency"><tt/Urgency/ +<p> + +This is a description of how important it is to upgrade to this +version from previous ones. It consists of a single keyword usually +taking one of the values <tt/LOW/, <tt/MEDIUM/ or <tt/HIGH/) followed +by an optional commentary (separated by a space) which is usually in +parentheses. For example: +<example> +Urgency: LOW (HIGH for diversions users) +</example> +<p> + +This field appears in the <tt/.changes/ file and in parsed changelogs; +its value appears as the value of the <tt/urgency/ attribute in a +<prgn/dpkg/-style changelog (see <ref id="dpkgchangelog">). +<p> + +Urgency keywords are not case-sensitive. + +<sect1 id="f-Date"><tt/Date/ +<p> + +In <tt/.changes/ files and parsed changelogs, this gives the date the +package was built or last edited. + +<sect1 id="f-Format"><tt/Format/ +<p> + +This field occurs in <tt/.changes/ files, and specifies a format +revision for the file. The format described here is version <tt/1.5/. +The syntax of the format value is the same as that of a package +version number except that no epoch or Debian revision is allowed - +see <ref id="versions">. + +<sect1 id="f-Changes"><tt/Changes/ +<p> + +In a <tt/.changes/ file or parsed changelog this field contains the +human-readable changes data, describing the differences between the +last version and the current one. +<p> + +There should be nothing in this field before the first newline; all +the subsequent lines must be indented by at least one space; blank +lines must be represented by a line consiting only of a space and a +full stop. +<p> + +Each version's change information should be preceded by a `title' line +giving at least the version, distribution(s) and urgency, in a +human-readable way. +<p> + +If data from several versions is being returned the entry for the most +recent version should be returned first, and entries should be +separated by the representation of a blank line (the `title' line may +also be followed by the representation of blank line). + +<sect1 id="f-Filename"><tt/Filename/ and <tt/MSDOS-Filename/ +<p> + +These fields in <tt/Packages/ files give the filename(s) of (the parts +of) a package in the distribution directories, relative to the root of +the Debian hierarchy. If the package has been split into several +parts the parts are all listed in order, separated by spaces. + +<sect1 id="f-Size"><tt/Size/ and <tt/MD5sum/ +<p> + +These fields in <tt/Packages/ files give the size (in bytes, expressed +in decimal) and MD5 checksum of the file(s) which make(s) up a binary +package in the distribution. If the package is split into several +parts the values for the parts are listed in order, separated by +spaces. + +<sect1 id="f-Status"><tt/Status/ +<p> + +This field in <prgn/dpkg/'s status file records whether the user wants a +package installed, removed or left alone, whether it is broken +(requiring reinstallation) or not and what its current state on the +system is. Each of these pieces of information is a single word. + +<sect1 id="f-Config-Version"><tt/Config-Version/ +<p> + +If a package is not installed or not configured, this field in +<prgn/dpkg/'s status file records the last version of the package which +was successfully configured. + +<sect1 id="f-Conffiles"><tt/Conffiles/ +<p> + +This field in <prgn/dpkg/'s status file contains information about the +automatically-managed configuration files held by a package. This +field should <em/not/ appear anywhere in a package! + +<sect1>Obsolete fields +<p> + +These are still recognised by <prgn/dpkg/ but should not appear anywhere +any more. + +<taglist compact> + +<tag><tt/Revision/ +<tag><tt/Package-Revision/ +<tag><tt/Package_Revision/ +<item> +The Debian revision part of the package version was at one point in a +separate control file field. This field went through several names. + +<tag><tt/Recommended/ +<item>Old name for <tt/Recommends/ + +<tag><tt/Optional/ +<item>Old name for <tt/Suggests/. + +<tag><tt/Class/ +<item>Old name for <tt/Priority/. + +</taglist> + +<chapt id="versions">Version numbering +<p> + +Every package has a version number, in its <tt/Version/ control file +field. +<p> + +<prgn/dpkg/ imposes an ordering on version numbers, so that it can tell +whether packages are being up- or downgraded and so that <prgn/dselect/ +can tell whether a package it finds available is newer than the one +installed on the system. The version number format has the most +significant parts (as far as comparison is concerned) at the +beginning. +<p> + +The version number format is: +&lsqb<var/epoch/<tt/:/]<var/upstream-version/[<tt/-/<var/debian-revision/]. +<p> + +The three components here are: + +<taglist> + +<tag><var/epoch/ +<item> + +This is a single unsigned integer, which should usually be small. It +may be omitted, in which case zero is assumed. If it is omitted then +the <var/upstream-version/ may not contain any colons. +<p> + +It is provided to allow mistakes in the version numbers of older +versions of a package, and also a package's previous version numbering +schemes, to be left behind. +<p> + +<prgn/dpkg/ will not usually display the epoch unless it is essential +(non-zero, or if the <var/upstream-version/ contains a colon); +<prgn/dselect/ does not display epochs at all in the main part of the +package selection display. + +<tag><var/upstream-version/ +<item> + +This is the main part of the version. It is usually version number of +the original (`upstream') package of which the <tt/.deb/ file has been +made, if this is applicable. Usually this will be in the same format +as that specified by the upstream author(s); however, it may need to +be reformatted to fit into <prgn/dpkg/'s format and comparison scheme. +<p> + +The comparison behaviour of <prgn/dpkg/ with respect to the +<var/upstream-version/ is described below. The <var/upstream-version/ +portion of the version number is mandatory. +<p> + +The <var/upstream-version/ may contain only alphanumerics and the +characters <tt/+/ <tt/./ <tt/-/ <tt/:/ (full stop, plus, hyphen, +colon) and should start with a digit. If there is no +<var/debian-revision/ then hyphens are not allowed; if there is no +<var/epoch/ then colons are not allowed. + +<tag><var/debian-revision/ +<item> + +This part of the version represents the version of the modifications +that were made to the package to make it a Debian binary package. It +is in the same format as the <var/upstream-version/ and <prgn/dpkg/ +compares it in the same way. +<p> + +It is optional; if it isn't present then the <var/upstream-version/ +may not contain a hyphen. This format represents the case where a +piece of software was written specifically to be turned into a Debian +binary package, and so there is only one `debianization' of it and +therefore no revision indication is required. +<p> + +It is conventional to restart the <var/debian-revision/ at <tt/1/ each +time the <var/upstream-version/ is increased. +<p> + +<prgn/dpkg/ will break the <var/upstream-version/ and +<var/debian-revision/ apart at the last hyphen in the string. The +absence of a <var/debian-revision/ compares earlier than the presence +of one (but note that the <var/debian-revision/ is the least +significant part of the version number). +<p> + +The <var/debian-revision/ may contain only alphanumerics and the +characters <tt/+/ and <tt/./ (plus and full stop). + +</taglist> + +The <var/upstream-version/ and <var/debian-revision/ parts are +compared by <prgn/dpkg/ using the same algorithm: +<p> + +The strings are compared from left to right. +<p> + +First the initial part of each string consisting entirely of non-digit +characters is determined. These two parts (one of which may be empty) +are compared lexically. If a difference is found it is returned. The +lexical comparison is a comparison of ASCII values modified so that +all the letters sort earlier than all the non-letters. +<p> + +Then the initial part of the remainder of each string which consists +entirely of digit characters is determined. The numerical values of +these two parts are compared, and any difference found is returned as +the result of the comparison. For these purposes an empty string +(which can only occur at the end of one or both version strings being +compared) counts as zero. +<p> + +These two steps are repeated (chopping initial non-digit strings and +initial digit strings off from the start) until a difference is found +or both strings are exhausted. +<p> + +Note that the purpose of epochs is to allow us to leave behind +mistakes in version numbering, and to cope with situations where the +version numbering changes. It is <em/not/ there to cope with version +numbers containing strings of letters which <prgn/dpkg/ cannot interpret +(such as <tt/ALPHA/ or <tt/pre-/), or with silly orderings (the author +of this manual has heard of a package whose versions went <tt/1.1/, +<tt/1.2/, <tt/1.3/, <tt/1/, <tt/2.1/, <tt/2.2/, <tt/2/ and so forth). +<p> + +If an upstream package has problematic version numbers they should be +converted to a sane form for use in the <tt/Version/ field. +<p> + +If you need to compare version numbers ina script, you may use +<tt>dpkg --compare-versions ...</>. Type <tt>dpkg --help</> --> +--for details on arguments. + +<chapt id="maintainerscripts">Package maintainer scripts +and installation procedure +<sect>Introduction to package maintainer scripts +<p> + +It is possible supply scripts as part of a package which <prgn/dpkg/ +will run for you when your package is installed, upgraded or removed. +<p> + +These scripts should be the files <tt/preinst/, <tt/postinst/, +<tt/prerm/ and <tt/postrm/ in the control area of the package. They +must be proper exectuable files; if they are scripts (which is +recommended) they must start with the usual <tt/#!/ convention. They +should be readable and executable to anyone, and not world-writeable. +<p> + +<prgn/dpkg/ looks at the exit status from these scripts. It is +important that they exit with a non-zero status if there is an error, +so that <prgn/dpkg/ can stop its processing. For shell scripts this +means that you <em/almost always/ need to use <tt/set -e/ (this is +usually true when writing shell scripts, in fact). It is also +important, of course, that they don't exit with a non-zero status if +everything went well. +<p> + +It is necessary for the error recovery procedures that the scripts be +idempotent: ie, invoking the same script several times in the same +situation should do no harm. If the first call failed, or aborted +half way through for some reason, the second call should merely do the +things that were left undone the first time, if any, and exit with a +success status. +<p> + +When a package is upgraded a combination of the scripts from the old +and new packages is called in amongst the other steps of the upgrade +procedure. If your scripts are going to be at all complicated you +need to be aware of this, and may need to check the arguments to your +scripts. +<p> + +Broadly speaking the <prgn/preinst/ is called before (a particular +version of) a package is installed, and the <prgn/postinst/ afterwards; +the <prgn/prerm/ before (a version of) a package is removed and the +<prgn/postrm/ afterwards. +<p> +<!-- + next paragraph by Guy Maor to close bug #2481 + --> + +Programs called from maintainer scripts should not normally have a +path prepended to them. Before installation is started <prgn/dpkg/ +checks to see if the programs <prgn/ldconfig/, +<prgn/start-stop-daemon/, <prgn/install-info/, and <prgn/update-rc.d/ +can be found via the <tt/PATH/ environment variable. Those programs, +and any other program that one would expect to on the <tt/PATH/, +should thus be invoked without an absolute pathname. Maintainer +scripts should also not reset the <tt/PATH/, though they might choose +to modify it by pre- or appending package-specific directories. These +considerations really apply to all shell scripts. + +<sect id="mscriptsinstact">Summary of ways maintainer scripts are called +<p> + +<list compact> +<item><var/new-preinst/ <tt/install/ +<item><var/new-preinst/ <tt/install/ <var/old-version/ +<item><var/new-preinst/ <tt/upgrade/ <var/old-version/ +<item><var/old-preinst/ <tt/abort-upgrade/ <var/new-version/ +</list> +<p> + +<list compact> +<item><var/postinst/ <tt/configure/ <var/most-recently-configured-version/ +<item><var/old-postinst/ <tt/abort-upgrade/ <var/new version/ +<item><var/conflictor's-postinst/ <tt/abort-remove/ + <tt/in-favour/ <var/package/ <var/new-version/ +<item><var/deconfigured's-postinst/ <tt/abort-deconfigure/ + <tt/in-favour/ <var/failed-install-package/ <var/version/ + <tt/removing/ <var/conflicting-package/ <var/version/ +</list> +<p> + +<list compact> +<item><var/prerm/ <tt/remove/ +<item><var/old-prerm/ <tt/upgrade/ <var/new-version/ +<item><var/new-prerm/ <tt/failed-upgrade/ <var/old-version/ +<item><var/conflictor's-prerm/ <tt/remove/ <tt/in-favour/ + <var/package/ <var/new-version/ +<item><var/deconfigured's-prerm/ <tt/deconfigure/ + <tt/in-favour/ <var/package-being-installed/ <var/version/ + <tt/removing/ <var/conflicting-package/ <var/version/ +</list> +<p> + +<list compact> +<item><var/postrm/ <tt/remove/ +<item><var/postrm/ <tt/purge/ +<item><var/old-postrm/ <tt/upgrade/ <var/new-version/ +<item><var/new-postrm/ <tt/failed-upgrade/ <var/old-version/ +<item><var/new-postrm/ <tt/abort-install/ +<item><var/new-postrm/ <tt/abort-install/ <var/old-version/ +<item><var/new-postrm/ <tt/abort-upgrade/ <var/old-version/ +<item><var/disappearer's-postrm/ <tt/disappear/ <var/overwriter/ <var/new-version/ +</list> + + +<sect id="unpackphase">Details of unpack phase of installation or upgrade +<p> + +The procedure on installation/upgrade/overwrite/disappear (ie, when +running <tt/dpkg --unpack/, or the unpack stage of <tt/dpkg +--install/) is as follows. In each case if an error occurs the +actions in are general run backwards - this means that the maintainer +scripts are run with different arguments in reverse order. These are +the `error unwind' calls listed below. + +<enumlist> +<item> + +<enumlist> +<item> +If a version the package is already +installed, call +<example> +<var/old-prerm/ upgrade <var/new-version/ +</example> + +<item> +If this gives an error (ie, a non-zero exit status), dpkg will +attempt instead: +<example> +<var/new-prerm/ failed-upgrade <var/old-version/ +</example> +Error unwind, for both the above cases: +<example> +<var/old-postinst/ abort-upgrade <var/new-version/ +</example> + +</enumlist> + +<item> +If a `conflicting' package is being removed at the same time: +<enumlist> + +<item> +If any packages depended on that conflicting package and +<tt/--auto-deconfigure/ is specified, call, for each such package: +<example> +<var/deconfigured's-prerm/ deconfigure \ + in-favour <var/package-being-installed/ <var/version/ \ + removing <var/conflicting-package/ <var/version/ +</example> +Error unwind: +<example> +<var/deconfigured's-postinst/ abort-deconfigure \ + in-favour <var/package-being-installed-but-failed/ <var/version/ \ + removing <var/conflicting-package/ <var/version/ +</example> +The deconfigured packages are marked as requiring configuration, so +that if <tt/--install/ is used they will be configured again if +possible. + +<item> +To prepare for removal of the conflicting package, call: +<example> +<var/conflictor's-prerm/ remove in-favour <var/package/ <var/new-version/ +</example> +Error unwind: +<example> +<var/conflictor's-postinst/ abort-remove \ + in-favour <var/package/ <var/new-version/ +</example> + +</enumlist> + +<item> +<enumlist> +<item> +If the package is being upgraded, call: +<example> +<var/new-preinst/ upgrade <var/old-version/ +</example> + +<item> +Otherwise, if the package had some configuration files from a previous +version installed (ie, it is in the `configuration files only' state): +<example> +<var/new-preinst/ install <var/old-version/ +</example> + +<item> +Otherwise (ie, the package was completely purged): +<example> +<var/new-preinst/ install +</example> +Error unwind versions, respectively: +<example> +<var/new-postrm/ abort-upgrade <var/old-version/ +<var/new-postrm/ abort-install <var/old-version/ +<var/new-postrm/ abort-install +</example> + +</enumlist> + +<item> +The new package's files are unpacked, overwriting any that may be on +the system already, for example any from the old version of the same +package or from another package (backups of the old files are left +around, and if anything goes wrong dpkg will attempt to put them back +as part of the error unwind). +<p> + +It is an error for a package to contains files which are on the system +in another package, unless <tt/Replaces/ is used (see +<ref id="replaces">). Currently the <tt/--force-overwrite/ flag is +enabled, downgrading it to a warning, but this may not always be the +case. +<p> + +It is a more serious error for a package to contain a plain file or +other kind of nondirectory where another package has a directory +(again, unless <tt/Replaces/ is used). This error can be overridden +if desired using <tt/--force-overwrite-dir/, but this is not advisable. +<p> + +Packages which overwrite each other's files produce behaviour which +though deterministic is hard for the system administrator to +understand. It can easily lead to `missing' programs if, for example, +a package is installed which overwrites a file from another package, +and is then removed again.<footnote>Part of the problem is due to what +is arguably a bug in <prgn/dpkg/.</footnote> +<p> + +A directory will never be replaced by a symbolic links to a directory +or vice versa; instead, the existing state (symlink or not) will be +left alone and <prgn/dpkg/ will follow the symlink if there is one. + +<item> + +<enumlist> +<item> +If the package is being upgraded, call +<example> +<var/old-postrm/ upgrade <var/new-version/ +</example> + +<item> +If this fails, <prgn/dpkg/ will attempt: +<example> +<var/new-postrm/ failed-upgrade <var/old-version/ +</example> +Error unwind, for both cases: +<example> +<var/old-preinst/ abort-upgrade <var/new-version/ +</example> + +</enumlist> + +This is the point of no return - if <prgn/dpkg/ gets this far, it won't +back off past this point if an error occurs. This will leave the +package in a fairly bad state, which will require a successful +reinstallation to clear up, but it's when <prgn/dpkg/ starts doing +things that are irreversible. + +<item> +Any files which were in the old version of the package but not in the +new are removed. + +<item> +The new file list replaces the old. + +<item> +The new maintainer scripts replace the old. + +<item> +Any packages all of whose files have been overwritten during the +installation, and which aren't required for dependencies, are considered +to have been removed. For each such package, + +<enumlist> +<item> +<prgn/dpkg/ calls: +<example> +<var/disappearer's-postrm/ disappear \ + <var/overwriter/ <var/overwriter-version/ +</example> + +<item> +The package's maintainer scripts are removed. + +<item> +It is noted in the status database as being in a sane state, namely +not installed (any conffiles it may have are ignored, rather than +being removed by <prgn/dpkg/). Note that disappearing packages do not +have their prerm called, because <prgn/dpkg/ doesn't know in advance +that the package is going to vanish. + +</enumlist> + +<item> +Any files in the package we're unpacking that are also listed in the +file lists of other packages are removed from those lists. (This will +lobotomise the file list of the `conflicting' package if there is one.) + +<item> +The backup files made during installation, above, are deleted. + +<item> +The new package's status is now sane, and recorded as `unpacked'. Here +is another point of no return - if the conflicting package's removal +fails we do not unwind the rest of the installation; the conflicting +package is left in a half-removed limbo. + +<item> +If there was a conflicting package we go and do the removal actions +(described below), starting with the removal of the conflicting +package's files (any that are also in the package being installed +have already been removed from the conflicting package's file list, +and so do not get removed now). + +</enumlist> + +<sect>Details of configuration +<p> + +When we configure a package (this happens with <tt/dpkg --install/, or +with <tt/--configure/), we first update the conffiles and then call: +<example> +<var/postinst/ configure <var/most-recently-configured-version/ +</example> +<p> + +No attempt is made to unwind after errors during configuration. +<p> + +If there is no most recently configured version <prgn/dpkg/ will pass a +null argument; older versions of dpkg may pass +<tt><unknown></tt> (including the angle brackets) in this case. +Even older ones do not pass a second argument at all, under any +circumstances. + +<sect>Details of removal and/or configuration purging +<p> + +<enumlist> +<item> +<example> +<var/prerm/ remove +</example> + +<item> +The package's files are removed (except conffiles). + +<item> +<example> +<var/postrm/ remove +</example> + +<item> +All the maintainer scripts except the postrm are removed. +<p> + +If we aren't purging the package we stop here. Note that packages +which have no postrm and no conffiles are automatically purged when +removed, as there is no difference except for the <prgn/dpkg/ status. + +<item> +The conffiles and any backup files (<tt/~/-files, <tt/#*#/ files, +<tt/%/-files, <tt/.dpkg-{old,new,tmp}/, etc.) are removed. + +<item> +<example> +<var/postrm/ purge +</example> + +<item> +The package's file list is removed. + +</enumlist> + +No attempt is made to unwind after errors during removal. + + +<chapt id="descriptions">Descriptions of packages - the +<tt/Description/ field +<p> + +The <tt/Description/ control file field is used by <prgn/dselect/ when +the user is selecting which packages to install and by <prgn/dpkg/ +when it displays information about the status of packages and so +forth. It is included on the FTP site in the <prgn/Packages/ files, +and may also be used by the Debian WWW pages. +<p> + +The description is intended to describe the program to a user who has +never met it before so that they know whether they want to install it. +It should also give information about the significant dependencies and +conflicts between this package and others, so that the user knows why +these dependencies and conflicts have been declared. +<p> + +The field's format is as follows: +<example> +Description: <var/single line synopsis/ + <var/extended description over several lines/ +</example> +<p> + +The synopsis is often printed in lists of packages and so forth, and +should be as informative as possible. Every package should also have +an extended description. +<p> + +<sect>Types of formatting line in the extended description +<p> + +<list> +<item> +Those starting with a single space are part of a paragraph. +Successive lines of this form will be word-wrapped when displayed. +The leading space will usually be stripped off. + +<item> +Those starting with two or more spaces. These will be displayed +verbatim. If the display cannot be panned horizontally the +displaying program will linewrap them `hard' (ie, without taking +account of word breaks). If it can they will be allowed to trail +off to the right. None, one or two initial spaces may be deleted, +but the number of spaces deleted from each line will be the same +(so that you can have indenting work correctly, for example). + +<item> +Those containing a single space followed by a single full stop +character. These are rendered as blank lines. This is the <em/only/ +way to get a blank line - see below. + +<item> +Those containing a space, a full stop and some more characters. These +are for future expansion. Do not use them. +</list> + +<sect>Notes about writing descriptions +<p> + +<em/Always/ start extended description lines with at least one +whitespace character. Fields in the control file and in the Packages +file are separated by field names starting in the first column, just +as message header fields are in RFC822. Forgetting the whitespace +will cause <prgn/dpkg-deb/<footnote>Version 0.93.23 or +later.</footnote> to produce a syntax error when trying to build the +package. If you force it to build anyway <prgn/dpkg/ will refuse to +install the resulting mess. +<p> + +<em/Do not/ include any completely <em/empty/ lines. These separate +different records in the Packages file and different packages in the +<tt>debian/control</> file, and are forbidden in package control +files. See the previous paragraph for what happens if you get this +wrong. +<p> + +The single line synopsis should be kept brief - certainly under 80 +characters. <prgn/dselect/ displays between 25 and 49 characters +without panning if you're using an 80-column terminal, depending on +what display options are in effect. +<p> + +Do not include the package name in the synopsis line. The display +software knows how to display this already, and you do not need to +state it. Remember that in many situations the user may only see +the synopsis line - make it as informative as you can. +<p> + +The extended description should describe what the package does and +how it relates to the rest of the system (in terms of, for +example, which subsystem it is which part of). +<p> + +The blurb that comes with a program in its announcements and/or +<prgn/README/ files is rarely suitable for use in a description. It +is usually aimed at people who are already in the community where the +package is used. The description field needs to make sense to anyone, +even people who have no idea about any of the +things the package deals with. +<p> + +Put important information first, both in the synopis and extended +description. Sometimes only the first part of the synopsis or of +the description will be displayed. You can assume that there will +usually be a way to see the whole extended description. +<p> + +You may include information about dependencies and so forth in the +extended description, if you wish. +<p> + +Do not use tab characters. Their effect is not predictable. +<p> + +Do not try to linewrap the summary (the part on the same line as the +field name <tt/Description/) into the extended description. This will +not work correctly when the full description is displayed, and makes +no sense where only the summary is available. + +<sect>Example description in control file for Smail +<p> + +<example> +Package: smail +Version: 3.1.29.1-13 +Maintainer: Ian Jackson <iwj10@cus.cam.ac.uk> +Recommends: pine | mailx | elm | emacs | mail-user-agent +Suggests: metamail +Depends: cron, libc5 +Conflicts: sendmail +Provides: mail-transport-agent +Description: Electronic mail transport system. + Smail is the recommended mail transport agent (MTA) for Debian. + . + An MTA is the innards of the mail system - it takes messages from + user-friendly mailer programs and arranges for them to be delivered + locally or passed on to other systems as required. + . + In order to make use of it you must have one or more user level + mailreader programs such as elm, pine, mailx or Emacs (which has Rmail + and VM as mailreaders) installed. If you wish to send messages other + than just to other users of your system you must also have appropriate + networking support, in the form of IP or UUCP. +</example> + +<chapt id="relationships">Declaring relationships between packages +<p> + +Packages can declare in their control file that they have certain +relationships to other packages - for example, that they may not be +installed at the same time as certain other packages, and/or that they +depend on the presence of others, or that they should overwrite files +in certain other packages if present. +<p> + +This is done using the <tt/Depends/, <tt/Recommends/, <tt/Suggests/, +<tt/Conflicts/, <tt/Provides/ and <tt/Replaces/ control file fields. +<p> + +<sect id="depsyntax">Syntax of relationship fields +<p> + +These fields all have a uniform syntax. They are a list of package +names separated by commas. +<p> + +In <tt/Depends/, <tt/Recommends/, <tt/Suggests/ and <tt/Pre-Depends/ +(the fields which declare dependencies of the package in which they +occur on other packages) these package names may also be lists of +alternative package names, separated by vertical bar symbols <tt/|/ +(pipe symbols). +<p> + +All the fields except <tt/Provides/ may restrict their applicability +to particular versions of each named package. This is done in +parentheses after each individual package name; the parentheses should +contain a relation from the list below followed by a version number, +in the format described in <ref id="versions">. +<p> + +The relations allowed are +<tt/<</, +<tt/<=/, +<tt/=/, +<tt/>=/ and +<tt/>>/ +for strictly earlier, earlier or equal, exactly equal, later or equal +and strictly later, respectively. The forms <tt/</ and <tt/>/ +were used to mean earlier/later or equal, rather than strictly +earlier/later, so they should not appear in new packages (though +<prgn/dpkg/ still supports them). +<p> + +Whitespace may appear at any point in the version specification, and +must appear where it's necessary to disambiguate; it is not otherwise +significant. For consistency and in case of future changes to +<prgn/dpkg/ it is recommended that a single space be used after a +version relationship and before a version number; it is usual also to +put a single space after each comma, on either side of each vertical +bar, and before each open parenthesis. +<p> + +For example: +<example> +Package: metamail +Version: 2.7-3 +Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh +</example> + +<sect>Dependencies - <tt/Depends/, <tt/Recommends/, <tt/Suggests/, <tt/Pre-Depends/ +<p> + +These four fields are used to declare a dependency by one package on +another. They appear in the depending package's control file. +<p> + +All but <tt/Pre-Depends/ (discussed below) take effect <em/only/ when +a package is to be configured. They do not prevent a package being on +the system in an unconfigured state while its dependencies are +unsatisfied, and it is possible to replace a package whose +dependencies are satisfied and which is properly installed with a +different version whose dependencies are not and cannot be satisfied; +when this is done the depending package will be left unconfigured +(since attempts to configure it will give errors) and will not +function properly. +<p> + +For this reason packages in an installation run are usually all +unpacked first and all configured later; this gives later versions of +packages with dependencies on later versions of other packages the +opportunity to have their dependencies satisfied. +<p> + +Thus <tt/Depends/ allows package maintainers to impose an order in +which packages should be configured. + +<taglist> +<tag><tt/Depends/ +<item> + +This declares an absolute dependency. +<p> + +<prgn/dpkg/ will not configure +packages whose dependencies aren't satisfied. If it is asked to make +an installation which would cause an installed package's dependencies +to become unsatisfied it will complain<footnote>Current versions +(1.2.4) of <prgn/dpkg/ have a bug in this area which will cause some of +these problems to be ignored.</footnote>, unless +<tt/--auto-deconfigure/ is specified, in which case those packages +will be deconfigured before the installation proceeds. +<p> + +<prgn/dselect/ makes it hard for the user to select packages for +installation, removal or upgrade in a way that would mean that +packages' <prgn/Depends/ fields would be unsatisfied. The user can +override this if they wish, for example if they know that <prgn/dselect/ +has an out-of-date view of the real package relationships. +<p> + +The <tt/Depends/ field should be used if the depended-on package is +required for the depending package to provide a significant amount of +functionality. + +<tag><tt/Recommends/ +<item> +This declares a strong, but not absolute, dependency. +<p> + +<tt/Recommends/ is ignored by <prgn/dpkg/, so that users using the +command-line (who are presumed to know what they're doing) will not be +impeded. +<p> + +It is treated by <prgn/dselect/ exactly as <tt/Depends/ is; this makes +it hard for the user to select things so as to leave <tt/Recommends/ +fields unsatisfied, but they are able to do so by being persistent. +<p> + +The <tt/Recommends/ field should list packages that would be found +together with this one in all but unusual installations. + +<tag><tt/Suggests/ +<item> + +This is used to declare that one package may be more useful with one +or more others. Using this field tells the packaging system and the +user that the listed packages are be related to this one and can +perhaps enhance its usefulness, but that installing this one without +them is perfectly reasonable. +<p> + +<prgn/dselect/ will offer suggsted packages to the system administrator +when they select the suggesting package, but the default is not to +install the suggested package. + +<tag><tt/Pre-Depends/ +<item> + +This field is like <tt/Depends/, except that it also forces <prgn/dpkg/ +to complete installation of the packages named before even starting +the installation of the package which declares the predependency. +<p> + +<prgn/dselect/ checks for predependencies when it is doing an +installation run, and will attempt to find the packages which are +required to be installed first and do so in the right order. +<p> + +However, this process is slow (because it requires repeated +invocations of <prgn/dpkg/) and troublesome (because it requires +guessing where to find the appropriate files). +<p> + +For these reasons, and because this field imposes restrictions on the +order in which packages may be unpacked (which can be difficult for +installations from multipart media, for example), <tt/Pre-Depends/ +should be used sparingly, preferably only by packages whose premature +upgrade or installation would hamper the ability of the system to +continue with any upgrade that might be in progress. +<p> + +When the package declaring it is being configured, a +<tt/Pre-Dependency/ will be considered satisfied only if the depending +package has been correctly configured, just as if an ordinary +<tt/Depends/ had been used. +<p> + +However, when a package declaring a predependency is being unpacked +the predependency can be satisfied even if the depended-on package(s) +are only unpacked or half-configured, provided that they have been +configured correctly at some point in the past (and not removed or +partially removed since). In this case both the previously-configured +and currently unpacked or half-configured versions must satisfy any +version clause in the <tt/Pre-Depends/ field. + +</taglist> + +When selecting which level of dependency to use you should consider +how important the depended-on package is to the functionality of the +one declaring the dependency. Some packages are composed of +components of varying degrees of importance. Such a package should +list using <tt/Depends/ the package(s) which are required by the more +important components. The other components' requirements may be +mentioned as Suggestions or Recommendations, as appropriate to the +components' relative importance. + +<sect1>Dependencies on shared libraries +<p> + +The dependency fields listed above are used by packages which need +shared libraries to declare dependencies on the appropriate packages. +<p> + +These dependencies are usually determined automatically using +<prgn/dpkg-shlibdeps/ and inserted in the package control file using +the control file substitution variables mechanism; see <ref +id="srcsubstvars"> and <ref id="sourcetools">. + +<sect1>Deconfiguration due to removal during bulk installations +<p> + +If <prgn/dpkg/ would like to remove a package due to a conflict, as +described above, but this would violate a dependency of some other +package on the system, <prgn/dpkg/ will usually not remove the +conflicting package and halt with an error. +<p> + +However, if the <tt/--auto-deconfigure/ (<tt/-B/) option is used +<prgn/dpkg/ will automatically `deconfigure' the package with the +problematic dependency, so that the conflicting package can be removed +and the package we're trying to install can be installed. If +<prgn/dpkg/ is being asked to install packages (rather than just +unpacking them) it will try to reconfigure the package when it has +unpacked all its arguments, in the hope that one of the other packages +it is installing will satisfy the problematic dependency. +<p> + +<prgn/dselect/ supplies this argument to <prgn/dpkg/ when it invokes it, +so that bulk installations proceed smoothly. + +<sect id="conflicts">Alternative packages - <tt/Conflicts/ and <tt/Replaces/ +<p> + +When one package declares a conflict with another <prgn/dpkg/ will +refuse to allow them to be installed on the system at the same time. +<p> + +If one package is to be installed, the other must be removed first - +if the package being installed is marked as replacing (<ref +id="replaces">) the one on the system, or the one on the system is +marked as deselected, or both packages are marked <tt/Essential/, then +<prgn/dpkg/ will automatically remove the package which is causing the +conflict, otherwise it will halt the installation of the new package +with an error. +<p> + +<prgn/dselect/ makes it hard to select conflicting packages, though the +user can override this if they wish. If they do not override it then +<prgn/dselect/ will select one of the packages for removal, and the user +must make sure it is the right one. In the future <prgn/dselect/ will +look for the presence of a <tt/Replaces/ field to help decide which +package should be installed and which removed. +<p> + +A package will not cause a conflict merely because its configuration +files are still installed; it must be at least half-installed. +<p> + +A special exception is made for packages which declare a conflict with +their own package name, or with a virtual package which they provide +(see below): this does not prevent their installation, and allows a +package to conflict with others providing a replacement for it. You +use this feature when you want the package in question to be the only +package providing something. +<p> + +A <tt/Conflicts/ entry should almost never have an `earlier than' +version clause. This would prevent <prgn/dpkg/ from upgrading or +installing the package which declared such a conflict until the +upgrade or removal of the conflicted-with package had been completed. +This aspect of installation ordering is not handled by <prgn/dselect/, +so that the use <tt/Conflicts/ in this way is likely to cause problems +for `bulk run' upgrades and installations. +<p> + + +<sect id="virtual">Virtual packages - <tt/Provides/ +<p> + +As well as the names of actual (`concrete') packages, the package +relationship fields <tt/Depends/, <tt/Recommends/, <tt/Suggests/ and +<tt/Conflicts/ may mention virtual packages. +<p> + +A virtual package is one which appears in the <tt/Provides/ control +file field of another package. The effect is as if the package(s) +which provide a particular virtual package name had been listed by +name everywhere were the virtual package name appears. +<p> + +If there are both a real and a virtual package of the same name then +the dependency may be satisfied (or the conflict caused) by either the +real package or any of the virtual packages which provide it. This is +so that, for example, supposing we have +<example> +Package: vm +Depends: emacs +</example> +and someone else releases an xemacs package they can say +<example> +Package: xemacs +Provides: emacs +</example> +and all will work in the interim (until a purely virtual package name +is decided on and the <tt/emacs/ and <tt/vm/ packages are changed to +use it). +<p> + +If a dependency or a conflict has a version number attached then only +real packages will be considered to see whether the relationship is +satisfied (or the prohibition violated, for a conflict) - it is +assumed that a real package which provides virtual package is not of +the `right' version. So, a <tt/Provides/ field may not contain +version numbers, and the version number of the concrete package which +provides a particular virtual package will not be looked at when +considering a dependency on or conflict with the virtual package name. +<p> + +It is likely that the ability will be added in a future release of +<prgn/dpkg/ to specify a version number for each virtual package it +provides. This feature is not yet present, however, and is expected +to be used only infrequently. +<p> + +If you want to specify which of a set of real packages should be the +default to satisfy a particular dependency on a virtual package, you +should list the real package as alternative before the virtual. +<p> + + +<sect id="replaces"><tt/Replaces/ - overwriting files and replacing packages +<p> + +The <tt/Replaces/ control file field has two purposes, which come into +play in different situations. +<p> + +Virtual packages (<ref id="virtual">) are not considered when looking +at a <tt/Replaces/ field - the packages declared as being replaced +must be mentioned by their real names. + +<sect1>Overwriting files in other packages +<p> + +Firstly, as mentioned before, it is usually an error for a package to +contains files which are on the system in another package, though +currently the <tt/--force-overwrite/ flag is enabled by default, +downgrading the error to a warning, +<p> + +If the overwriting package declares that it replaces the one +containing the file being overwritten then <prgn/dpkg/ will proceed, and +replace the file from the old package with that from the new. The +file will no longer be listed as `owned' by the old package. +<p> + +If a package is completely replaced in this way, so that <prgn/dpkg/ +does not know of any files it still contains, it is considered to have +disappeared. It will be marked as not wanted on the system (selected +for removal) and not installed. Any conffiles details noted in the +package will be ignored, as they will have been taken over by the +replacing package(s). The package's <prgn/postrm/ script will be run to +allow the package to do any final cleanup required. +See <ref id="mscriptsinstact">. +<p> + +In the future <prgn/dpkg/ will discard files which overwrite those from +another package which declares that it replaces the one being +installed (so that you can install an older version of a package +without problems). +<p> + +This usage of <tt/Replaces/ only takes effect when both packages are +at least partially on the system at once, so that it can only happen +if they do not conflict or if the conflict has been overridden. + +<sect1>Replacing whole packages, forcing their removal +<p> + +Secondly, <tt/Replaces/ allows <prgn/dpkg/ and <prgn/dselect/ to resolve +which package should be removed when a conflict - see +<ref id="conflicts">. This usage only takes effect when the two +packages <em/do/ conflict, so that the two effects do not interfere +with each other. +<p> + +<sect>Defaults for satisfying dependencies - ordering +<p> + +Ordering is significant in dependency fields. +<p> + +Usually dselect will suggest to the user that they select the package +with the most `fundamental' class (eg, it will prefer Base packages to +Optional ones), or the one that they `most wanted' to select in some +sense. +<p> + +In the absence of other information <prgn/dselect/ will offer a +default selection of the first named package in a list of +alternatives. +<p> + +However, there is no way to specify the `order' of several packages +which all provide the same thing, when that thing is listed as a +dependency. +<p> + +Therefore a dependency on a virtual package should contain a concrete +package name as the first alternative, so that this is the default. +<p> + +For example, consider the set of packages: + +<example> +Package: glibcdoc +Recommends: info-browser + +Package: info +Provides: info-browser + +Package: emacs +Provides: info-browser +</example> +<p> + +If <prgn/emacs/ and <prgn/info/ both have the same priority then +<prgn/dselect/'s choice is essentially random. Better would be +<example> +Package: glibcdoc +Recommends: info | info-browser +</example> +so that <prgn/dselect/ defaults to selecting the lightweight standalone +info browser. + + + +<chapt id="conffiles">Configuration file handling +<p> + +<prgn/dpkg/ can do a certain amount of automatic handling of package +configuration files. +<p> + +Whether this mechanism is appropriate depends on a number of factors, +but basically there are two approaches to any particular configuration +file. +<p> + +The easy method is to ship a best-effort configuration in the package, +and use <prgn/dpkg/'s conffile mechanism to handle updates. If the user +is unlikely to want to edit the file, but you need them to be able to +without losing their changes, and a new package with a changed version +of the file is only released infrequently, this is a good approach. +<p> + +The hard method is to build the configuration file from scratch in the +<prgn/postinst/ script, and to take the responsibility for fixing any +mistakes made in earlier versions of the package automatically. This +will be appropriate if the file is likely to need to be different on +each system. + +<sect>Automatic handling of configuration files by <prgn/dpkg/ +<p> + +A package may contain a control area file called <tt/conffiles/. This +file should be a list of filenames of configuration files needing +automatic handling, separated by newlines. The filenames should be +absolute pathnames, and the files referred to should actually exist in +the package. +<p> + +When a package is upgraded <prgn/dpkg/ will process the configuration +files during the configuration stage, shortly before it runs the +package's <prgn/postinst/ script, +<p> + +For each file it checks to see whether the version of the file +included in the package is the same as the one that was included in +the last version of the package (the one that is being upgraded +from); it also compares the version currently installed on the system +with the one shipped with the last version. +<p> + +If neither the user nor the package maintainer has changed the file, +it is left alone. If one or the other has changed their version, then +the changed version is preferred - ie, if the user edits their file, +but the package maintainer doesn't ship a different version, the +user's changes will stay, silently, but if the maintainer ships a new +version and the user hasn't edited it the new version will be +installed (with an informative message). If both have changed their +version the user is prompted about the problem and must resolve the +differences themselves. +<p> + +The comparisons are done by calculating the MD5 message digests of the +files, and storing the MD5 of the file as it was included in the most +recent version of the package. +<p> + +When a package is installed for the first time <prgn/dpkg/ will install +the file that comes with it, unless that would mean overwriting a file +already on the filesystem. +<p> + +However, note that <prgn/dpkg/ will <em/not/ replace a conffile that +was removed by the user (or by a script). This is necessary because +with some programs a missing file produces an effect hard or +impossible to achieve in another way, so that a missing file needs to +be kept that way if the user did it. +<p> + +Note that a package should <em/not/ modify a <prgn/dpkg/-handled +conffile in its maintainer scripts. Doing this will lead to +<prgn/dpkg/ giving the user confusing and possibly dangerous options +for conffile update when the package is upgraded. + +<sect>Fully-featured maintainer script configuration handling +<p> + +For files which contain site-specific information such as the hostname +and networking details and so forth, it is better to create the file +in the package's <prgn/postinst/ script. +<p> + +This will typically involve examining the state of the rest of the +system to determine values and other information, and may involve +prompting the user for some information which can't be obtained some +other way. +<p> + +When using this method there are a couple of important issues which +should be considered: +<p> + +If you discover a bug in the program which generates the configuration +file, or if the format of the file changes from one version to the +next, you will have to arrange for the postinst script to do something +sensible - usually this will mean editing the installed configuration +file to remove the problem or change the syntax. You will have to do +this very carefully, since the user may have changed the file, perhaps +to fix the very problem that your script is trying to deal with - you +will have to detect these situations and deal with them correctly. +<p> + +If you do go down this route it's probably a good idea to make the +program that generates the configuration file(s) a separate program in +<tt>/usr/sbin</>, by convention called <tt/<var/package/config/ and +then run that if appropriate from the post-installation script. The +<tt/<var/package/config/ program should not unquestioningly overwrite +an existing configuration - if its mode of operation is geared towards +setting up a package for the first time (rather than any arbitrary +reconfiguration later) you should have it check whether the +configuration already exists, and require a <tt/--force/ flag to +overwrite it. + + + +<chapt id="alternatives">Alternative versions of an interface - +<prgn/update-alternatives/ +<p> + +When several packages all provide different versions of the same +program or file it is useful to have the system select a default, but +to allow the system administrator to change it and have their +decisions respected. +<p> + +For example, there are several versions of the <prgn/vi/ editor, and +there is no reason to prevent all of them from being installed at +once, each under their own name (<prgn/nvi/, <prgn/vim/ or whatever). +Nevertheless it is desirable to have the name <tt/vi/ refer to +something, at least by default. +<p> + +If all the packages involved cooperate, this can be done with +<prgn/update-alternatives/. +<p> + +Each package provides its own version under its own name, and calls +<prgn/update-alternatives/ in its postinst to register its version +(and again in its prerm to deregister it). +<p> + +See the manpage <manref name=update-alternatives section=8> for +details. +<p> + +If <prgn/update-alternatives/ does not seem appropriate you may wish +to consider using diversions instead. + + +<chapt id="diversions">Diversions - overriding a package's version of a file +<p> + +It is possible to have <prgn/dpkg/ not overwrite a file when it +reinstalls the package it belongs to, and to have it put the file from +the package somewhere else instead. +<p> + +This can be used locally to override a package's version of a file, or +by one package to override another's version (or provide a wrapper for +it). +<p> + +Before deciding to use a diversion, read <ref id="alternatives"> to +see if you really want a diversion rather than several alternative +versions of a program. +<p> + +There is a diversion list, which is read by <prgn/dpkg/, and updated +by a special program <prgn/dpkg-divert/. Please see <manref +name=dpkg-divert section=8> for full details of its operation. +<p> + +When a package wishes to divert a file from another, it should call +<prgn/dpkg-divert/ in its preinst to add the diversion and rename the +existing file. For example, supposing that a <prgn/smailwrapper/ +package wishes to install a wrapper around <tt>/usr/sbin/smail</>: +<example> +if [ install = "$1" ]; then + dpkg-divert --package smailwrapper --add --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail +fi +</example> +Testing <tt/$1/ is necessary so that the script doesn't try to add the +diversion again when <prgn/smailwrapper/ is upgraded. The +<tt/--package smailwrapper/ ensures that <prgn/smailwrapper/'s copy of +<tt>/usr/sbin/smail</> can bypass the diversion and get installed as +the true version. +<p> + +The postrm has to do the reverse: +<example> +if [ remove = "$1" ]; then + dpkg-divert --package smailwrapper --remove --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail +fi +</example> +<p> + +Do not attempt to divert a file which is vitally important for the +system's operation - when using <prgn/dpkg-divert/ there is a time, +after it has been diverted but before <prgn/dpkg/ has installed the +new version, when the file does not exist. + + +<chapt id="sharedlibs">Shared libraries +<p> + +Packages containing shared libraries must be constructed with a little +care to make sure that the shared library is always available. This +is especially important for packages whose shared libraries are +vitally important, such as the libc. +<p> + +Firstly, your package should install the shared libraries under their +normal names. For example, the <prgn/libgdbm1/ package should install +<tt/libgdbm.so.1.7.3/ as <tt>/usr/lib/libgdbm.so.1.7.3</tt>. The +files should not be renamed or relinked by any prerm or postrm +scripts; <prgn/dpkg/ will take care of renaming things safely without +affecting running programs, and attempts to interfere with this are +likely to lead to problems. +<p> + +Secondly, your package should include the symlink that <prgn/ldconfig/ +would create for the shared libraries. For example, the +<prgn/libgdbm1/ package should include a symlink from +<tt>/usr/lib/libgdbm.so.1</tt> to <tt/libgdbm.so.1.7.3/. This is +needed so that <prgn/ld.so/ can find the library in between the time +<prgn/dpkg/ installs it and <prgn/ldconfig/ is run in the +<prgn/postinst/ script. Futhermore, and <em/this is very important/, +the library must be placed before the symlink pointing to it in the +<tt/.deb/ file. This is so that by the time <prgn/dpkg/ comes to +install the symlink (overwriting the previous symlink pointing at an +older version of the library) the new shared library is already in +place. Currently the way to ensure the ordering is done properly is +to install the library in the appropriate <tt>debian/tmp/.../lib</> +directory before creating the symlink, by putting the commands in the +<tt>debian/rules</> in the appropriate order. +<p> + +<!-- + next Paragraph added to close Bug #5299, Guy Maor + --> + +Thirdly, the development package should contain a symlink for the +shared library without a version number. For example, the +<tt/libgdbm1-dev/ package should include a symlink from +<tt>/usr/lib/libgdm.so</> to <tt/libgdm.so.1.7.3/. This symlink is +needed by <prgn/ld/ when compiling packages as it will only look for +<tt/libgdm.so/ and <tt/libgdm.a/ when compiling dynamically or +statically, respectively. +<p> + +<!-- + next paragraph changed by Christian Schwarz (see policy weekly #6) + --> + +Any package installing shared libraries in a directory that's listed +in <tt>/etc/ld.so.conf</tt> or in one of the default library +directories of <prgn/ld.so/ (currently, these are <tt>/usr/lib</tt> +and <tt>/lib</tt>) must call <prgn/ldconfig/ in its <prgn/postinst/ +script if and only if the first argument is `configure'. However, it +is important not to call <prgn/ldconfig/ in the postrm or preinst +scripts in the case where the package is being upgraded (see <ref +id="unpackphase">), as <prgn/ldconfig/ will see the temporary names +that <prgn/dpkg/ uses for the files while it is installing them and +will make the shared library links point to them, just before +<prgn/dpkg/ continues the installation and removes the links! +<p> + +<!-- + moved from section 2.2 , DMorris + --> + +<sect id="shlibs">The <tt/shlibs/ File Format +<p> + +This file is for use by <prgn/dpkg-shlibdeps/ and is required when +your package provides shared libraries. +<p> + +Each line is of the form: +<example> +<var/library-name/ <var/version-or-soname/ <var/dependencies .../ +</example> +<p> + +<var/library-name/ is the name of the shared library, for example +<tt/libc5/. +<p> + +<var/version-or-soname/ is the soname of the library - ie, the thing +that must exactly match for the library to be recognised by +<prgn/ld.so/. Usually this is major version number of the library. +<p> + +<var/dependencies/ has the same syntax as a dependency field in a +binary package control file. It should give details of which +package(s) are required to satisfy a binary built against the version +of the library contained in the package. See <ref id="depsyntax">. +<p> + +For example, if the package <tt/foo/ contains <tt/libfoo.so.1.2.3/, +where the soname of the library is <tt/libfoo.so.1/, and the first +version of the package which contained a minor number of at least +<tt/2.3/ was <var/1.2.3-1/, then the package's <var/shlibs/ could +say: +<example> +libfoo 1 foo (>= 1.2.3-1) +</example> +<p> + +The version-specific dependency is to avoid warnings from <prgn/ld.so/ +about using older shared libraries with newer binaries. + +<sect>Further Technical information on <tt/shlibs/</> + +<!-- + following section mostly provided by Heiko Schlittermann + edited by DMorris + --> + +<sect1><em/What/ are the <tt/shlibs/ files? +<p> + +The <tt>debian/shlibs</> file provides a way of checking +for shared library dependencies on packaged binaries. They are +intended to be used by package maintainers to make their lives easier. +<p> + +Other <tt/shlibs/ files that exist on a Debian system are +<list> +<item> <tt>/etc/dpkg/shlibs.default</> +<item> <tt>/etc/dpkg/shlibs.override</> +<item> <tt>/var/lib/dpkg/info/*.shlibs</> +<item> <tt>debian/shlibs.local</> +</list> + +These files are used by <prgn/dpkg-shlibdeps/ when creating a binary +package. + +<sect1><em/How/ does <prgn/dpkg-shlibdeps/ work? +<p> + +<prgn/dpkg-shlibdeps/ calls <prgn/ldd/ to determine the shared libraries +used by the compiled binaries passed through its command line. +<p> + +For each shared library, <prgn/dpkg-shlibdeps/ needs to know +<list compact> +<item>the package containing the library, and +<item>the library version number, +</list> +<p> +it scans the following files in this order. +<enumlist compact> +<item><tt>debian/shlibs.local</> +<item><tt>/etc/dpkg/shlibs.override</> +<item><tt>/var/lib/dpkg/info/*.shlibs</> +<item><tt>/etc/dpkg/shlibs.default</> +</enumlist> + +<sect1><em/Who/ maintains the various <tt/shlibs/ files? +<p> + +<list compact> +<item><tt>/etc/dpkg/shlibs.default</> - the maintainer of dpkg +<item><tt>/var/lib/dpkg/info/<var/package/.shlibs</> - the maintainer of each +package +<item><tt>/etc/dpkg/shlibs.override</> - the local system administrator +<item><tt>debian/shlibs.local</> - the maintainer of the package +</list> + +The <tt/shlibs.default/ file is managed by <prgn/dpkg/. The entries in +<tt/shlibs.default/ that are provided by <prgn/dpkg/ are just there to +fix things until the shared library packages all have <tt/shlibs/ +files. + +<sect1><em/How/ to use <prgn/dpkg-shlibdeps/ and the <tt/shlibs/ files? + +<sect2>If your package doesn't provide a shared library +<p> + +Put a call to <prgn/dpkg-shlibs/ into your <tt>debian/rules</> file. +If your package contains only binaries (e.g. no scripts) use: +<example> +dpkg-shlibdeps debian/tmp/usr/{bin,sbin}/* +</example> + +If <prgn/dpkg-shlibdeps/ doesn't complain, you're done. If it does +complain you might need to create your own <tt>debian/shlibs.local</> +file. + +<sect2>If your package provides a shared library +<p> + +Create a <tt>debian/shlibs</> file and let <tt>debian/rules</> install +it in the control area: + +<example> +install -m644 debian/shlibs debian/tmp/DEBIAN +</example> + +If your package contains additional binaries see above. + +<sect1><em/How/ to write <tt>debian/shlibs.local</> +<p> + +This file is intended only as a <em/temporary/ fix if your binaries +depend on a library which doesn't provide its own +<tt>/var/lib/dpkg/*.shlibs</> file yet. +<p> + +Let's assume you are packaging a binary <tt/foo/. Your output in +building the package might look like this. + +<example> +$ ldd foo +libbar.so.1 => /usr/X11R6/lib/libbar.so.1.0 +libc.so.5 => /lib/libc.so.5.2.18 +libX11.so.6 => /usr/X11R6/lib/libX11.so.6.0 +</example> + +And when you ran <prgn/dpkg-shlibdeps/ + +<example> +$ dpkg-shlibdeps -o foo +dpkg-shlibdeps: warning: unable to find dependency information +for shared library libbar +(soname 1, path /usr/X11R6/lib/libbar.so.1.0, dependency field Depends) +shlibs:Depends=elf-x11r6lib, libc5 (>= 5.2.18) +</example> + +The <prgn/foo/ binary depends on the <prgn/libbar/ shared library, but +no package seems to provide a <tt/*.shlibs/ file in +<tt//var/lib/dpkg/info/. Let's determine the package responsible: +<p> + +<example> +$ dpkg -S /usr/X11R6/lib/libbar.so.1.0 +bar1: /usr/X11R6/lib/libbar.so.1.0 +$ dpkg -s bar1 | grep Version +Version: 1.0-1 +</example> + +This tells us that the <prgn/bar1/ package, version 1.0-1 is the one +we are using. Now we can create our own <tt>debian/shlibs.local</> to +temporarly fix the above problem. Include the following line into your +<tt>debian/shlibs.local</> file. + +<example> + libbar 1 bar1 (>= 1.0-1) +</example> + +Now your package build should work. As soon as the maintainer of +<prgn/libbar1/ provides a <tt/shlibs/ file, you can remove your +<tt>debian/shlibs.local</> file. + +<chapt id="methif"><prgn/dselect/'s interface to its installation methods +<p> + +<prgn/dselect/ calls scripts from its installation methods when it +needs to actually access data from the distribution. The core program +<prgn/dselect/ itself just calls these scripts and provides the +package and access method selection interfaces. The installation +methods are responsible for invoking <prgn/dpkg/ as appropriate. +<p> + +Each installation method has three scripts: +<list compact> +<item>Setup installation parameters. +<item>Update list of available packages. +<item>Install. +</list> +<p> + +<prgn/dselect/ searches for methods in <tt>/usr/lib/dpkg/methods</> +and <tt>/usr/local/lib/dpkg/methods</>. + +<sect>Functions of the method scripts +<p> + +The setup script is run just after the user has chosen an installation +method. It should prompt the user for parameters like the site to +NFS-mount or FTP from, the directory to use, or the directory or +filesystem where the <tt/.deb/ files can be found, or the tape or +floppy device to install from. It should store the responses under +<tt>/var/lib/dpkg/methods</> - see below. If no available +packages list is available it should perhaps offer to scan the +available packages. +<p> + +The update script should obtain a list of available packages if +possible, and run <tt/dpkg --update-avail/, <tt/dpkg --merge-avail/ +and/or <tt/dpkg --forget-old-unavail/ to load it into <prgn/dpkg/ and +<prgn/dselect/'s database of available packages. If no packages list +was available and the user was offered and accepted the option of +scanning the actual files available this scan should be done here, +using <tt/dpkg --record-avail/. +<p> + +The install script should feed all the available <tt/.deb/ files to +<tt/dpkg --iGOEB/ (this is equivalent to <tt/dpkg --install +--refuse-downgrade --selected-only --skip-same-version +--auto-deconfigure/). The <tt/-R/ (<tt/--recursive/) option for +traversing subdirectories may also be useful here). +<p> + +If any of these scripts needs to display a message for the user, it +should wait for the user to hit `return' before exiting so that +dselect doesn't immediately rewrite the screen. +<p> + +If a method script succeeds (returns a zero exit status) +<prgn/dselect/ will return immediately to the main menu, with the +`next' option highlighted ready for the user to select it. If it +fails <prgn/dselect/ will display a message and wait for the user to +hit return. + +<sect>Location and arguments of the method scripts +<p> + +A set of scripts (henceforth known as a group) may provide several +methods on the `main menu' with different behaviour. For example, +there might be a generic get-packages-by-FTP group which might provide +methods in the main menu for installation directly from one of the +Debian mirror sites as well as for installation from a user-specified +site. +<p> + +Each group of methods implemented by the same set of scripts should +have a subdirectory <tt>/usr/lib/dpkg/methods/<var/group/</> or +<tt>/usr/local/lib/dpkg/methods/<var/group/</>, containing: +<taglist compact> +<tag><tt/names/ +<item>a list of user-visible methods provided by these scripts. +<tag><tt/setup/ +<tag><tt/update/ +<tag><tt/install/ +<item>executable programs, the scripts themselves. +<tag><tt/desc.<var/option// +<item>description file. +</taglist> +<p> + +<tt/names/ will be formatted as a list of lines, each containing: +<example> +<var/sequence/ <var/method/ <var/summary/ +</example> +<p> + +<var/sequence/ is a two-digit number that will be used much like +<tt/rc.d/ prefixes to control the order in the main menu. If in doubt +use 50. +<p> + +<var/method/ is a name which is displayed by <prgn/dselect/ as the +name of the method, and which will be passed to <tt/setup/, +<tt/update/ and <tt/unpack/ as their first argument. +<p> + +<var/summary/ is the brief description string for <prgn/dselect/'s menu. +<p> + +Each of the three scripts gets the same three arguments: <var/vardir/, +<var/group/ and <var/method/. <var/vardir/ is the base directory for +storing <prgn/dpkg/ and <prgn/dselect/'s state, usually +<tt>/var/lib/dpkg</>; this is passed in so that the <tt/--admindir/ +option to <prgn/dselect/ is honoured). +<p> + +Each option may have an extended description in +<tt/desc.<var/option//. This should be formatted like the extended +description part of a <tt/Description/ field entry <em/shifted one +character to the left/. +<p> + +<tt><var/vardir//methods</> will exist, and a method group may use a +<tt><var/vardir//methods/<var/group/</> directory to store its state. +<p> + +The group name and method name must follow the rules for C identifiers. + +<chapt id="conversion">Conversion procedure from old source packages +<p> + +This is a brief summary of the procedure for converting a +pre-2.0.0.0-format source package into the new format. +<p> + +You are strongly advised to download and examine the <prgn/hello/ +package, and to read the section in the <prgn/dpkg/ programmers' +manual describing the source packaging tools. More detail about the +exact functionality of these tools is available in <manref +name=dpkg-source section=1>. +<p> + +<list> + +<item> +Download the original source code from wherever it can be found and do +any rearrangement required to make it look like the original tree of +the Debian source. Put it in +<tt><var/package/-<var/upstream-version/.orig/</> or +<tt/<var/package/_<var/upstream-version/.orig.tar.gz/. + +<item> +Rename all files <tt/debian.*/ to <tt>debian/*</>. There may be some +exceptions to this, but this is a good start. + +<item> +Edit the <tt>debian/changelog</> - create or rename it if necessary. +Add a new revision to the top with the appropriate details, and a +local variables entry to the bottom to set Emacs to the right mode: +<example> +Local variables: +mode: debian-changelog +End: +</example> + +<item> +Edit/create <tt>debian/control</>: +<list compact> +<item> +Remove the <tt/Version/ field. If it is generated unusually (not +equal to the source version) you must use the -v option to +dpkg-gencontrol (see below). <tt/Section/, <tt/Priority/, +<tt/Maintainer/ go above the first blank line, most of the rest below. + +<item> +Reorder the fields and add a blank line at an appropriate point, +separating the source package fields from the binary package +fields. + +<item> +Add the <tt/Source/ field. + +<item> +Add the <tt/Standards-Version/ field. (Please check out the Debian +Policy Manual for details about this field.) + +<item> +Change the <tt/Architecture/ field for each package to <tt/any/, +<tt/all/ or whatever. If there isn't an <tt/Architecture/ field add +one. + +<item> +If any other use of sed or things used to happen to make the binary +control files use <prgn/dpkg-gencontrol/'s variable substitution +features to achieve the same effect. Use <tt>debian/substvars</> if +you need to put unusally-generated information (apart from details of +<tt/.deb/ files) in the <tt/.changes/ file too. +</list> + +<item> +Edit the <tt>debian/rules</>: +<list compact> +<item> +Remove the <prgn/source/ and <prgn/diff/ and any <prgn/changes/ and +<prgn/dist/ targets. These things now happen in a package-independent +way and are not done by <tt>debian/rules</>. +<item> +Split the <prgn/binary/ target into <prgn/binary-arch/ and +<prgn/binary-indep/; in many cases all of <prgn/binary/ should go into +<prgn/binary-arch/. Create the <prgn/binary/ target and the unused of +the two other <prgn/binary-*/ targets if there is one - you can copy +the ones from the <prgn/hello/ package. +<item> +Change the <prgn/binary/ target to use <prgn/dpkg-gencontrol/ to make +the package control file(s). Move it to after all the files have been +installed but just before the last <prgn/chown/ and <prgn/chmod/ in +the target. +<item> +Change occurrences of <tt/debian-tmp/ to <tt>debian/tmp</>. +<item> +Change occurrences of <tt/debian.{post,pre}{inst,rm}/ to +<tt>debian/*</>. +<item> +Remove the version number setting at the top, if there is one. +<item> +Ensure that the package's Debian-specific and upstream changelogs are +installed. +</list> + +<item> +Change the package to use <prgn/dpkg-shlibdeps/ to determine its +shared library dependencies and substitute them in. Shared library +dependencies should no longer be hardwired in the source package. + +<item> +Check that the <tt>debian/README</> is really the copyright file, and +if so rename it to <tt>debian/copyright</> and edit +<tt>debian/rules</> to cope with this and to change the installation +of the copyright file from <tt>/usr/doc/<var/package//copyright</> +to <tt>/usr/doc/copyright/<var/package/</>. If it isn't then +find <tt>debian/copyright</> and decide what to do with the +<tt>README</>. + +<item> +Check for various other anachronisms and problems: +<list compact> +<item> +Remove any <tt/Package_Revision/, <tt/Package-Revision/ or +<tt/Revision/ fields. +<item> +Rename <tt/Optional/ to <tt/Suggests/, <tt/Recommended/ to +<tt/Recommends/. +<item> +Change <tt>/usr/doc/examples/<var/package/</> to +<tt>/usr/doc/<var/package//examples</>. +<item> +Make sure that manpages are installed compressed. +<item> +Check that the description has an extended description, is +well-formatted and meaningful and helpful to people wanting to know +whether to install a package. +</list> + +<item> +Look everything over. + +<item> +Do a test build using <tt/dpkg-buildpackage -us -uc -sa +-r<var/whatever//. Check the permissions and locations of files in +the resulting package by examining the output of <tt/dpkg-deb +--contents/, and check that the source build happened OK. Test +install the binary package(s) and test extract the source package(s). + +<item> +Sign the release: either rebuild everything with <tt/dpkg-buildpackage +-sa/, or PGP-sign the <tt/.dsc/, rebuild the <tt/.changes/ using +<tt/dpkg-genchanges -sa/, and then PGP-sign the <tt/.changes/. + +</list> +<p> + +The use of <tt/-sa/ on <prgn/dpkg-buildpackage/ and +<prgn/dpkg-genchanges/ is important when doing the first +build/uploading of a new-format source package. Unless this happens +to be Debian revision <tt/0/ or <tt/1/ by default the original source +tarfile will not be included in the uploaded files listed in the +<tt/.changes/ file, and so it won't be installed on the FTP site. +<tt/-sa/ requests that the original source be included regardless. + +</book> diff --git a/policy.sgml b/policy.sgml new file mode 100644 index 0000000..d88c754 --- /dev/null +++ b/policy.sgml @@ -0,0 +1,2591 @@ +<!doctype debiandoc system [ +<!-- include version information so we don't have to hard code it + within the document --> +<!entity % versiondata SYSTEM "version.ent"> %versiondata; +]> +<debiandoc> +<!-- + Debian GNU/Linux Policy Manual. + Copyright (C)1996,1997,1998 Ian Jackson and Christian Schwarz; + released under the terms of the GNU + General Public License, version 2 or (at your option) any later. + Initial version 1996, Ian Jackson, ijackson@gnu.ai.mit.edu + Revised November 27, 1996, David A. Morris, bweaver@debian.org + New sections March 15, 1997, Christian Schwarz, schwarz@debian.org + Reworked/Restructured April-July 1997, Christian Schwarz, schwarz@debian.org + Maintainer since 1997, Christian Schwarz, schwarz@debian.org + Christoph Lameter contributed the "Web Standard" + --> + +<book> + +<title>Debian Policy Manual +<author>Ian Jackson <email/ijackson@gnu.ai.mit.edu/ +<author>Christian Schwarz <email/schwarz@debian.org/ +<author>revised: David A. Morris <email/bweaver@debian.org/ +<version>version &version;, &date; + +<abstract> +This manual describes the policy requirements for the Debian GNU/Linux +distribution. This includes the structure and contents of the Debian +archive, several design issues of the operating system, as well as +technical requirements that each package must satisfy to be included +in the distribution. +</abstract> + +<copyright>Copyright ©1996,1997,1998 Ian Jackson and Christian Schwarz. +<p> + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. +<p> + +This is distributed in the hope that it will be useful, but +<em>without any warranty</em>; without even the implied warranty of +merchantability or fitness for a particular purpose. See the GNU +General Public License for more details. +<p> + +A copy of the GNU General Public License is available as +<tt>/usr/doc/copyright/GPL</tt> in the Debian GNU/Linux +distribution or on the World Wide Web at +<url id="http://www.gnu.org/copyleft/gpl.html">. You can also obtain it +by writing to the Free Software Foundation, Inc., 59 Temple Place - +Suite 330, Boston, MA 02111-1307, USA. +<p> + +<toc sect> + +<chapt id="scope">About this manual +<p> + +<sect>Scope +<p> + +This manual describes the policy requirements for the Debian GNU/Linux +distribution. This includes the structure and contents of the Debian +archive, several design issues of the operating system, as well as +technical requirements that each package must satisfy to be included +in the distribution. +<p> + +This manual does <em/not/ describe the technical mechanisms involved +in package creation, installation, and removal. This information can +be found in the <em>Debian Packaging Manual</em> and the <em>Debian +System Administrators' Manual</em>. +<p> + +This document assumes familiarity with these other two manuals. +Unfortunately, the <em>System Administrators' Manual</em> does not +exist yet. +<p> + +Much of the information presented in this manual will be useful even +when building a package which is to be distributed in some other way +or is for local use. +<p> + +<sect>New versions of this document +<p> + +The current version of this document is always accessible from the +Debian FTP server at +<url id="ftp://ftp.debian.org/debian/doc/manuals/debian-policy.html.tar.gz"> +or from the Debian WWW server at +<url id="http://www.debian.org/doc/manuals/debian-policy/"> +<p> + +There is also a home page for the <em>Debian Policy Manual</em> that +contains links to the current development version of this document as +well as an archive of old versions. The URL is +<url id="http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/"> +<p> + +In addition, this manual is distributed via the Debian package +<tt>debian-policy</tt> +<p> + +<sect>Feedback +<p> + +As the Debian GNU/Linux system is continuously evolving this manual is +changed from time to time. +<p> + +While the authors of this document tried hard not to include any typos +or other errors these still occur. If you discover an error in this +manual or if you want to tell us any comments, suggestions, or critics +please send an email to the Debian Policy Manager, Christian +Schwarz <email>schwarz@debian.org</email>, the developers' mailing +list <email>debian-devel@lists.debian.org</email>, or submit a bug report +against the <tt>debian-policy</tt> package. +<p> + +<chapt>The Debian Archive +<p> + +The Debian GNU/Linux system is maintained and distributed as a +collection of <em>packages</em>. Since there are so many of them (over +1000) they are split into <em>sections</em> and <em>priorities</em> to +simplify handling of them. +<p> + +The effort of the Debian project is to build a free operating system, +but not every package we want to make accessible is <em>free</em> in +our sense (see Debian Free Software Guidelines, below), or may be +imported/exported without restrictions. Thus, the archive is split +into the sections <em/main/, <em/non-us/, <em/non-free/, and +<em/contrib/. +<p> + +The <em/main/ section forms the <em>Debian GNU/Linux distribution</em>. +<p> + +Packages in the other sections are not considered as part of the +Debian distribution, though we support their use, and we provide +infrastructure for them (such as our bug-tracking system and mailing +lists). This Debian Policy Manual applies to these packages as well. +<p> + +<sect id="pkgcopyright">Package copyright and sections +<p> + +The aims of this policy are: +<p> + +<list compact> +<item> +We want to make as much software available as we can.<p> +<item> +We want to encourage everyone to write free software.<p> +<item> +We want to make it easy for people to produce CD-ROMs of our system +without violating any licenses, import/export restrictions, or any +other laws.<p> +</list> +<p> + +<sect1>The Debian Free Software Guidelines +<p> + +The Debian Free Software Guidelines (DFSG) as is our definition of `free' +software. +<p> + +<enumlist> +<item>Free Redistribution +<p> +The license of a Debian component may not restrict any party from +selling or giving away the software as a component of an aggregate +software distribution containing programs from several different +sources. The license may not require a royalty or other fee for such +sale. +<p> + +<item>Source Code +<p> + +The program must include source code, and must allow distribution in +source code as well as compiled form. +<p> + +<item>Derived Works +<p> + +The license must allow modifications and derived works, and must allow +them to be distributed under the same terms as the license of the original +software. +<p> + +<item>Integrity of The Author's Source Code +<p> + +The license may restrict source-code from being distributed in modified +form <em/only/ if the license allows the distribution of ``patch files'' +with the source code for the purpose of modifying the program at build +time. The license must explicitly permit distribution of software built +from modified source code. The license may require derived works to +carry a different name or version number from the original software. +(This is a compromise. The Debian group encourages all authors to not + restrict any files, source or binary, from being modified.) +<p> + +<item>No Discrimination Against Persons or Groups +<p> + +The license must not discriminate against any person or group of +persons. +<p> + +<item>No Discrimination Against Fields of Endeavor +<p> + +The license must not restrict anyone from making use of the program +in a specific field of endeavor. For example, it may not restrict the +program from being used in a business, or from being used for genetic +research. +<p> + +<item>Distribution of License +<p> + +The rights attached to the program must apply to all to whom the +program is redistributed without the need for execution of an +additional license by those parties. +<p> + +<item>License Must Not Be Specific to Debian +<p> + +The rights attached to the program must not depend on the program's +being part of a Debian system. If the program is extracted from Debian +and used or distributed without Debian but otherwise within the terms +of the program's license, all parties to whom the program is redistributed +should have the same rights as those that are granted in conjunction with +the Debian system. +<p> + +<item>License Must Not Contaminate Other Software +<p> + +The license must not place restrictions on other software that is +distributed along with the licensed software. For example, the +license must not insist that all other programs distributed on the +same medium must be free software. +<p> + +<item>Example Licenses +<p> +The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are examples of licenses +that we consider <em/free/. + +</enumlist> +<p> + +<sect1>The main section +<p> + +Every package in "main" must comply with the DFSG (Debian Free +Software Guidelines). +<p> + +In addition, the packages in "main" +<p> + +<list compact> +<item>must not require a package outside of "main" for compilation or +execution (thus, the package may not declare a "Depends" or +"Recommends" relationship on a non-main package), +<p> +<item>must not be so buggy that we refuse to support them, +<p> +<item>must meet all policy requirements presented in this manual. +</list> +<p> + +<sect1>The contrib section +<p> + +Every package in "contrib" must comply with the DFSG. +<p> + +Examples of packages which would be included in "contrib" are +<p> +<list compact> +<item>free packages which require "contrib", "non-free", or "non-US" + packages or packages which are not in our archive at all for + compilation or execution, +<p> +<item>wrapper packages or other sorts of free accessories for + non-free programs, +<p> +<item>packages which we don't want to support because they are too + buggy, and +<p> +<item>packages which fail to meet some other policy requirements in + a serious way. +</list> +<p> + +<sect1>The non-free section +<p> + +`Non-free' contains packages which are not compliant with the DFSG +or which are encumbered by patents or other legal issues that make +their distribution problematic. +<p> + +All packages in `non-free' must be electronically distributable across +international borders. +<p> + +<sect1>The non-us server +<p> + +Some programs with cryptographic program code must be stored on the +"non-us" server because of export restrictions of the U.S. +<p> + +This applies only to packages which contain cryptographic code. A package +containing a program with an interface to a cryptographic program or a +program that's dynamically linked against a cryptographic library can be +distributed if it is capable of running without the cryptography library +or program. +<p> + +<sect1>Further copyright considerations +<p> + +Every package must be accompanied by a verbatim copy of its copyright +and distribution license in the file +/usr/doc/<package-name>/copyright (see <ref id="copyrightfile"> +for details). +<p> + +We reserve the right to restrict files from being included anywhere in +our archives if +<p> +<list compact> +<item>their use or distribution would break a law, +<p> +<item>there is an ethical conflict in their distribution or use, +<p> +<item>we would have to sign a license for them, or +<p> +<item>their distribution would conflict with other project policies. +</list> +<p> + +Programs whose authors encourage the user to make donations are fine +for the main distribution, provided that the authors do not claim that +not donating is immoral, unethical, illegal or something similar; +otherwise they must go in contrib (or non-free, if even distribution +is restricted by such statements). +<p> + +Packages whose copyright permission notices (or patent problems) do +not allow redistribution even of only binaries, and where no special +permission has been obtained, cannot be placed on the Debian FTP site and +its mirrors at all. +<p> + +Note, that under international copyright law (this applies in +the United States, too) <em/no/ distribution or +modification of a work is allowed without an explicit notice saying +so. Therefore a program without a copyright notice <em/is/ +copyrighted and you may not do anything to it without risking being +sued! Likewise if a program has a copyright notice but no statement +saying what is permitted then nothing is permitted. +<p> + +Many authors are unaware of the problems that restrictive copyrights +(or lack of copyright notices) can cause for the users of their +supposedly-free software. It is often worthwhile contacting such +authors diplomatically to ask them to modify their license +terms. However, this is a politically difficult thing to do and you +should ask for advice on <tt/debian-devel/ first. +<p> + +When in doubt, send mail to <email/debian-devel@lists.debian.org/. Be +prepared to provide us with the copyright statement. Software covered +by the GPL, public domain software and BSD-like copyrights are safe; +be wary of the phrases `commercial use prohibited' and `distribution +restricted'. +<p> + +<sect1>Subsections +<p> + +The packages in the <em/main/, <em/contrib/, and <em/non-free/ +sections are grouped further into <em>subsections</em> to simplify +handling of them. +<p> + +The section for each package is specified in the package's <em>control +record</em>. However, the maintainer of the Debian archive may +override this selection to assure the consistency of the Debian +distribution. +<p> + +Please check the current Debian distribution to see which sections are +available. +<p> + +<sect>Priorities +<p> + +Each package is given a certain <em>priority</em> value, which is +included in the package's <em>control +record</em>. This information is used in the Debian package management +tool to separate high-priority packages from less-important packages. +<p> + +The following <em>priority levels</em> are supported by the Debian +package management system, <prgn/dpkg/. +<p> + +<taglist> +<tag><tt/required/ +<item> +<tt/required/ packages are necessary for the proper functioning of the +system. You must not remove these packages or your system may become +totally broken and you may not even be able to use +<prgn/dpkg/ to put things back. Systems with only the <tt/required/ +packages are probably unusable, but they do have enough functionality +to allow the sysadmin to boot and install more software. + +<tag><tt/important/ +<item> +Important programs, including those which one would expect to find on +any Unix-like system. If the expectation is that an experienced Unix +person who found it missing would say `What the F*!@<+ is going on, +where is <prgn/foo/', it should be in <tt/important/. This is an +important criterion because we are trying to produce, amongst other +things, a free Unix. Other packages without which the system will not +run well or be usable should also be here. This does <em/not/ +include Emacs or X11 or TeX or any other large applications. The +<tt/important/ packages are just a bare minimum of commonly-expected +and necessary tools. + +<tag><tt/standard/ +<item> +These packages provide a reasonably small but not too limited +character-mode system. This is what will install by default if the +user doesn't select anything else. It doesn't include many large +applications, but it does include Emacs (this is more of a piece of +infrastructure than an application) and a reasonable subset of TeX and +LaTeX (if this is possible without X). + +<tag><tt/optional/ +<item> +(In a sense everything is optional that isn't required, but that's not +what is meant here.) This is all the software that you might +reasonably want to install if you didn't know what it was or don't +have specialised requirements. This is a much larger system and includes +X11, a full TeX distribution, and lots of applications. + +<tag><tt/extra/ +<item> +This contains packages that conflict with others with higher +priorities, or are only likely to be useful if you already know what +they are or have specialised requirements. + +</taglist> +<p> + +Packages may not depend on packages with lower priority values. +If this should happen, one of the priority values will have to +be adapted. +<p> + +<sect>Binary packages +<p> + +The Debian GNU/Linux distribution is based on the Debian package +management system, called <prgn/dpkg/. Thus, all packages in the +Debian distribution have to be provided in the <tt/.deb/ file format. +<p> + +<sect1>The package name +<p> + +Every package must have a name that's unique within the Debian +archive. +<p> + +Package names may only consist of lower case letters, digits (0-9), +plus (+) or minus (-) signs, and periods (.). +<p> + +The package name is part of the file name of the <tt/.deb/ file and is +included in the control field information. +<p> + +<sect1>The maintainer of a package +<p> + +Every package must have exactly one maintainer at a time. This person +is responsible that the license of the package's software complies with +the policy of the distribution this package is included in. +<p> + +The maintainer must be specified in the <tt/Maintainer/ control field +with the correct name and a working email address for the Debian +maintainer of the package. If one person maintains several packages +he/she should try to avoid having different forms of their name and +email address in different <tt/Maintainer/ fields. +<p> + +If the maintainer of a package quits from the Debian project the +Debian QA Group takes over the maintainership of the package until +someone else volunteers for that task. These packages are called +<em>orphaned packages</em>. +<p> + +<sect1>The description of a package +<p> + +Every Debian package should have an extended description stored in the +appropriate field of the control record. +<p> + +The description should be written so that it tells the user what they +need to know to decide whether to install the package. This +description should not just be copied from the blurb for the program. +Instructions for configuring or using the package should not be +included--that is what installation scripts, manual pages, Info files, +etc. are for. Copyright statements and other +administrivia should not be included--that is what the copyright file +is for. +<p> + +<sect1>Dependencies +<p> + +Every package has to specify the dependency information about other +packages, that are required for the first to work correctly. +<p> + +For example, for any shared libraries required by dynamically-linked +executable binary in a package a dependency entry has to be provided. +<p> + +It is not necessary for other packages to declare any dependencies +they have on other packages which are marked <tt/Essential/ (see below). +<p> + +Sometimes, a package requires another package to be installed +<em>and</em> configured before it can be installed. In this case, +you'll have to specify a <tt/Pre-Depends/ entry for the package. +<p> + +You must not specify a <tt/Pre-Depends/ entry for a package before +this has been discussed on the <tt/debian-devel/ mailing list and a +consensus about doing that has been reached. +<p> + +<sect1>Virtual packages +<p> + +Sometimes, there are several packages doing more-or-less the same +job. In this case, it's useful to define a <em>virtual package</em> +who's name describes the function the packages have. (The virtual +packages just exist logically, not physically--that's why they are +called <em>virtual</em>.) The packages with this particular function +will then <em>provide</em> the virtual package. Thus, any other +package requiring that function can simply depend on the virtual +package without having to specify all possible packages individually. +<p> + +All packages must use virtual package names where appropriate, and +arrange to create new ones if necessary. They must not use virtual +package names (except privately, amongst a cooperating group of +packages) unless they have been agreed upon and appear in the list of +virtual package names. +<p> + +The latest version of the authoritative list of virtual package names +can be found on <ftpsite>ftp.debian.org</> in +<ftppath>/debian/doc/package-developer/virtual-package-names-list.text</> +or your local mirror. In addition, it is included in the +<tt>debian-policy</tt> package. The procedure for updating the list is +described at the top of the file. +<p> + +<sect1>Base packages +<p> + +The packages included in the <tt/base/ section have a special +function. They form a minimum subset of the Debian GNU/Linux system +that is installed before everything else on a new system. Thus, only +very few packages are allowed to go into the <tt/base/ section to keep +the required disk usage very small. +<p> + +Most of these packages should have the priority value <tt/required/ or +at least <tt/important/, and many of them will be tagged +<tt/essential/ (see below). +<p> + +You must not place any packages into the <tt/base/ section before this +has been discussed on the <tt/debian-devel/ mailing list and a +consensus about doing that has been reached. +<p> + +<sect1>Essential packages +<p> + +Some packages are tagged <tt/essential/. (They have <tt/Essential: +yes/ in their package control record.) This flag is used for packages +that are <em>essential</em> for a system. +<p> + +Since these packages can not easily be removed (you'll have to specify +an extra <em>force option</em> to <prgn/dpkg/) this flag should only +be used where absolutely necessary. + +A shared library package should not be tagged <em>essential</em>--the +dependencies will prevent its premature removal, and we need to be +able to remove it when it has been superseded. +<p> + +You must not tag any packages <tt/essential/ before this has been +discussed on the <tt/debian-devel/ mailing and a consensus about doing +that has been reached. +<p> + +<sect1>Maintainer scripts +<p> + +The package installation scripts should avoid producing output which +it is unnecessary for the user to see and should rely on <prgn/dpkg/ +to stave off boredom on the part of a user installing many packages. +This means, amongst other things, using the <tt/--quiet/ option on +<prgn/install-info/. +<p> + +Packages should try to minimise the amount of prompting they need to +do, and they should ensure that the user will only ever be asked each +question once. This means that packages should try to use appropriate +shared configuration files (such as <tt>/etc/papersize</> and +<tt>/etc/nntpserver</>), rather than each prompting for their own list +of required pieces of information. +<p> + +It also means that an upgrade should not ask the same questions again, +unless the user has used <tt/dpkg --purge/ to remove the package's +configuration. The answers to configuration questions should be +stored in an appropriate place in <tt>/etc</> so that the user can +modify them, and how this has been done should be documented. +<p> + +If a package has a vitally important piece of information to pass to +the user (such as "don't run me as I am, you must edit the following +configuration files first or you risk your system emitting +badly-formatted messages"), it should display this in the +<prgn/postinst/ script and prompt the user to hit return to +acknowledge the message. Copyright messages do not count as vitally +important (they belong in <tt>/usr/doc/copyright</>); neither do +instructions on how to use a program (these should be in on line +documentation, where all the users can see them). +<p> + +Any necessary prompting should almost always be confined to the +post-installation script, and should be protected with a conditional +so that unnecessary prompting doesn't happen if a package's +installation fails and the <prgn/postinst/ is called with +<tt/abort-upgrade/, <tt/abort-remove/ or <tt/abort-deconfigure/. +<p> + +Errors which occur during the execution of an installation script +<em/must/ be checked and the installation <em/must not/ continue after +an error. +<p> + +Note, that <ref id="scripts">, in general applies to package +maintainer scripts, too. +<p> + +Do not use <prgn/dpkg-divert/ on a file belonging to another package +without consulting the maintainer of that package first. +<p> + +In order for <prgn/update-alternatives/ to work correctly all the +packages which supply an instance of the `shared' command name (or, in +general, filename) must use it. You can use <tt/Conflicts/ to force +the deinstallation of other packages supplying it which do not (yet) +use <prgn/update-alternatives/. It may in this case be appropriate to +specify a conflict on earlier versions on something--this is an +exception to the usual rule that this is not allowed. +<p> + +<sect>Source packages +<p> + +<sect1>Standards conformance +<p> + +You should specify the most recent version of the packaging standards +with which your package complies in the source package's +<tt/Standards-Version/ field. +<p> + +This value will be used to file bug reports automatically if your +package becomes too much out of date. +<p> + +The value corresponds to a version of the Debian manuals, as can be +found on the title page or page headers and footers (depending on the +format). +<p> + +The version number has four components--major and minor number and +major and minor patch level. When the standards change in a way that +requires every package to change the major number will be changed. +Significant changes that will require work in many packages will be +signaled by a change to the minor number. The major patch level will +be changed for any change to the meaning of the standards, however +small; the minor patch level will be changed when only cosmetic, +typographical or other edits which do not change the meaning are made, +or changes which do not affect the contents of packages. +<p> + +You should regularly, and especially if your package has become out of +date, check for the newest Policy Manual available and update your +package, if necessary. When your package complies with the new +standards you may update the <tt/Standards-Version/ source package +field and release it. +<p> + +<sect1>Changes to the upstream sources +<p> + +If changes to the source code are made that are generally applicable +please try to get them included in the upstream version of the package +by supplying the upstream authors with the changes in whatever form +they prefer. +<p> + +If you need to configure the package differently for Debian or for +Linux, and the upstream source doesn't provide a way to configure it +the way you need to, please add such configuration facilities (for +example, a new <prgn/autoconf/ test or <tt/#define/) and send the +patch to the upstream authors, with the default set to the way they +originally had it. You can then easily override the default in your +<tt>debian/rules</tt> or wherever is appropriate. +<p> + +Please make sure that the <prgn/configure/ utility detects the correct +architecture specification string (refer to <ref id="arch-spec"> for +details). +<p> + +If you need to edit a <prgn/Makefile/ where GNU-style <prgn/configure/ +scripts are used, you should edit the <tt/.in/ files rather than +editing the <prgn/Makefile/ directly. This allows the user to +reconfigure the package if necessary. You should <em/not/ configure +the package and edit the generated <prgn/Makefile/! This makes it +impossible for someone else to later reconfigure the package. +<p> + +<sect1>Documenting your changes +<p> + +Document your changes and updates to the source package properly in +the <tt>debian/changelog</tt> file. +<p> + +A copy of the file which will be installed in +<tt>/usr/doc/<var/package//copyright</tt> should be in +<tt>debian/copyright</tt>. +<p> + +In non-experimental packages you may only use a format for +<tt>debian/changelog</> which is supported by the most recent released +version of <prgn/dpkg/. If your format is not supported and there is +general support for it you should contact the <prgn/dpkg/ maintainer +to have the parser script for your format included in the <prgn/dpkg/ +package. (You will need to agree that the parser and its +manpage may be distributed under the GNU GPL, just as the rest of +<prgn/dpkg/ is.) +<p> + +<sect1>Error trapping in makefiles +<p> + +When <prgn/make/ invokes a command in a makefile (including your +package's upstream makefiles and the <tt>debian/rules</>) it does so +using <tt/sh/. This means that <tt/sh/'s usual bad error handling +properties apply: if you include a miniature script as one of the +commands in your makefile you'll find that if you don't do anything +about it then errors are not detected and <prgn/make/ will blithely +continue after problems. +<p> + +Every time you put more than one shell command (this includes using a +loop) in a makefile command you <em/must/ make sure that errors are +trapped. For simple compound commands, such as changing directory and +then running a program, using <tt/&&/ rather than semicolon as +a command separator is sufficient. For more complex commands +including most loops and conditionals you must include a separate +<tt/set -e/ command at the start of every makefile command that's +actually one of these miniature shell scripts. +<p> + +<sect1>Obsolete constructs and libraries +<p> + +The include file <prgn/<varargs.h>/ is provided to support +end-users compiling very old software; the library <tt/libtermcap/ is +provided to support the execution of software which has been linked +against it (either old programs or those such as Netscape which are +only available in binary form). +<p> + +Debian packages should be ported to include <prgn/<stdarg.h>/ and +<tt/ncurses/ when they are built. +<p> + +<chapt>The Operating System +<p> + +<sect>Filesystem hierarchy +<p> + +<sect1>Linux Filesystem Structure +<p> + +The location of all installed files and directories must comply fully +with the Linux Filesystem Structure (FSSTND). The latest version of +this document can be found alongside this manual or on +<ftpsite/tsx-11.mit.edu/ in +<ftppath>/pub/linux/docs/linux-standards/fsstnd/</>. Specific +questions about following the standard may be asked on +<prgn/debian-devel/, or referred to Daniel Quinlan, the FSSTND +coordinator, at <email/quinlan@pathname.com/. +<p> + +<sect1>Site-specific programs +<p> + +As mandated by the FSSTND no package should place any files in +<tt>/usr/local</>, either by putting them in the filesystem archive to +be unpacked by <prgn/dpkg/ or by manipulating them in their maintainer +scripts. +<p> + +However, the package should create empty directories below +<tt>/usr/local</> so that the system administrator knows where to +place site-specific files. These directories should be removed on +package removal if they are empty. +<p> + +Note, that this applies only to directories <em/below/ +<tt>/usr/local</>, not <em/in/ <tt>/usr/local</>. The directory +<tt>/usr/local</> itself may only contain the sub-directories listed +in FSSTND, section 4.8. However, you may create directories below them +as you wish. You may not remove any of the directories listed in 4.8, +even if you created them. +<p> + +Since <tt>/usr/local</> may be mounted read-only from a remote server, +these directories have to be created and removed by the <tt/postinst/ +and <tt/prerm/ maintainer scripts. These scripts must not fail if +either of these operations fail. (In the future, it will be possible to +tell <prgn/dpkg/ not to unpack files matching certain patterns, so +that the directories can be included in the <tt/.deb/ packages and +system administrators who do not wish these directories in /usr/local +do not need to have them.) +<p> + +For example, the <prgn/emacs/ package will contain +<example> + mkdir -p /usr/local/lib/emacs/site-lisp || true +</example> +in the <tt/postinst/ script, and +<example> + rmdir /usr/local/lib/emacs/site-lisp && \ + rmdir /usr/local/lib/emacs || \ + true +</example> +in the <tt/prerm/ script. +<p> + +If you do create a directory in <tt>/usr/local</> for local additions +to a package, you must ensure that settings in <tt>/usr/local</tt> +take precedence over the equivalents in <tt>/usr</tt>. +<p> + +The <tt>/usr/local</> directory itself and all the subdirectories +created by the package should have permissions 2775 (group-writable +and set-group-id) and be owned by <tt/root.staff/. +<p> + +<sect>Users and groups +<p> + +The Debian system can be configured to use either plain or shadow +passwords. +<p> + +Some user ids (UIDs) and group ids (GIDs) are reserved globally for +use by certain packages. Because some packages need to include files +which are owned by these users or groups, or need the ids compiled +into binaries, these ids must be used on any Debian system only for +the purpose for which they are allocated. This is a serious +restriction, and we should avoid getting in the way of local +administration policies. In particular, many sites allocate users +and/or local system groups starting at 100. +<p> + +Apart from this we should have dynamically allocated ids, which should +by default be arranged in some sensible order--but the behaviour +should be configurable. +<p> + +No package except <tt>base-passwd</> may modify <tt>/etc/passwd</>, +<tt>/etc/shadow</>, or <tt>/etc/group</>. +<p> + +The UID and GID ranges are as follows: +<taglist> +<tag>0-99: +<item> +Globally allocated by the Debian project, must be the same on +every Debian system. These ids will appear in the <tt>passwd</> and +<tt>group</> +files of all Debian systems, new ids in this range being added +automatically as the <tt>base-passwd</> package is updated. +<p> + +Packages which need a single statically allocated uid or gid should +use one of these; their maintainers should ask the <tt>base-passwd</> +maintainer for ids. +<p> + +<tag>100-999: +<item> +Dynamically allocated system users and groups. Packages +which need a user or group, but can have this user or group allocated +dynamically and differently on each system, should use `<tt>adduser +--system</>' to create the group and/or user. <prgn>adduser</> will +check for the +existence of the user or group, and if necessary choose an unused id +based on the ranged specified in <tt>adduser.conf</>. +<p> + +<tag>1000-29999: +<item> +Dynamically allocated user accounts. By default <prgn>adduser</> +will choose UIDs and GIDs for user accounts in this range, though +<tt>adduser.conf</> may be used to modify this behaviour. +<p> + +<tag>30000-59999: +<item> +Reserved. +<p> + +<tag>60000-64999: +<item> +Globally allocated by the Debian project, but only created on +demand. The ids are allocated centrally and statically, but the actual +accounts are only created on users' systems on demand. +<p> + +These ids are for packages which are obscure or which require many +statically-allocated ids. These packages should check for and create +the accounts in <tt>/etc/passwd</> or <tt>/etc/group</> (using +<prgn>adduser</> if it has this facility) if necessary. Packages +which are likely to require further allocations should have a `hole' +left after them in the allocation, to give them room to grow. +<p> + +<tag>65000-65533: +<item> +Reserved. +<p> + +<tag>65534: +<item> +User `<tt>nobody</>.' +<p> + +<tag>65535: +<item> +<tt>(uid_t)(-1) == (gid_t)(-1)</>. NOT TO BE USED, because it is the +error return sentinel value. +<p> +</taglist> + +<sect>Files +<p> + +<sect1>Binaries +<p> + +It is not allowed that two packages install programs with different +functionality but with the same filenames. (The case of two programs +having the same functionality but different implementations is handled via +`alternatives.') If this case happens, one of the programs has to be +renamed. The maintainers should report this to the developers' mailing +and try to find a consensus about which package will have to be renamed. +If a consensus can not be reached, <em>both</> programs must be renamed. +<p> + +Generally the following compilation parameters should be used: +<example> + CC = gcc + CFLAGS = -O2 -g -Wall # sane warning options vary between programs + LDFLAGS = # none + install -s # (or use strip on the files in debian/tmp) +</example> +<p> + +Note that all installed binaries should be +stripped, either by using the <tt/-s/ flag to <prgn/install/, or by calling +<prgn/strip/ on the binaries after they have been copied into +<tt>debian/tmp</> but before the tree is made into a package. +<p> + +The <tt/-g/ flag is useful on compilation so that you have available a +full set of debugging symbols in your built source tree, in case +anyone should file a bug report involving (for example) a core dump. +<p> + +The <tt/-N/ flag should not be used. On a.out systems it may have +been useful for some very small binaries, but for ELF it has no good +effect. +<p> + +It is up to the package maintainer to decide what compilation options +are best for the package. Certain binaries (such as +computationally-intensive programs) may function better with certain +flags (<tt/-O3/, for example); feel free to use them. Please use good +judgment here. Don't use flags for the sake of it; only use them if +there is good reason to do so. Feel free to override the upstream +author's ideas about which compilation options are best--they are +often inappropriate for our environment. +<p> + +<sect1>Libraries +<p> + +All libraries must have a shared version in the lib package and a static +version in the lib-dev package. The shared version must be compiled with +<tt/-fPIC/, and the static version must not be. In other words, each +<tt/*.c/ file is compiled twice. +<p> + +You have to specify the gcc option <tt>-D_REENTRANT</tt> when building +a library (either static or shared) to make the library compatible with +LinuxThreads. +<p> + +Note that all installed shared libraries should be stripped with +<example> + strip --strip-unneeded <your-lib> +</example> +(The option `--strip-unneeded' makes <tt>strip</tt> remove only the symbols +which aren't needed for relocation processing.) +Shared libraries can function perfectly well when +stripped, since the symbols for dynamic linking are in a separate part +of the ELF object file. +<p> + +Note that under some circumstances +it may be useful to install a shared library unstripped, for example +when building a separate package to support debugging. +<p> + +Please make sure that you use only released versions of shared +libraries to build your packages; otherwise other users will not be +able to run your binaries properly. Producing source packages that +depend on unreleased compilers is also usually a bad idea. +<p> + +<sect1>Shared libraries +<p> + +Packages involving shared libraries should be split up into several +binary packages. +<p> + +For a straightforward library which has a development environment and +a runtime kit including just shared libraries you need to create two +packages: <tt/<var/libraryname/<var/soname// (<var/soname/ is +the shared object name of the shared library--it's the thing that has +to match exactly between building an executable and running it for the +dynamic linker to be able run the program; usually the <var/soname/ +is the major number of the library) and +<tt/<var/libraryname/<var/soname/-dev/. +<p> + +If you prefer only to support one development version at a time you +may name the development package <tt/<var/libraryname/-dev/; otherwise +you may wish to use <prgn/dpkg/'s conflicts mechanism to ensure that +the user only installs one development version at a time (after all, +different development versions are likely to have the same header +files in them, causing a filename clash if both are installed). +Typically the development version will also need an exact version +dependency on the runtime library, to make sure that compilation and +linking happens correctly. +<p> + +Packages which use the shared library should have a dependency on the +name of the shared library package, +<tt/<var/libraryname/<var/soname//. When the <var/soname/ changes you +can have both versions of the library installed while moving from the +old library to the new. +<p> + +If your package has some run-time support programs which use the +shared library you must <em/not/ put them in the shared library +package. If you do that then you won't be able to install several +versions of the shared library without getting filename clashes. +Instead, either create a third package for the runtime binaries (this +package might typically be named <tt/<var/libraryname/-runtime/--note +the absence of the <var/soname/ in the package name) or if the +development package is small include them in there. +<p> + +If you have several shared libraries built from the same source tree +you can lump them all together into a single shared library package, +provided that you change all their <var/soname/s at once (so that you +don't get filename clashes if you try to install different versions of +the combined shared libraries package). +<p> + +Follow the directions in the <em>Debian Packaging Manual</em> for +putting the shared library in its package, and make sure you include a +<tt/shlibs/ control area file with details of the dependencies for +packages which use the library. +<p> + +Shared libraries should <em/not/ be installed executable, since +<prgn/ld.so/ does not require this and trying to execute a shared +library results in a core dump. +<p> + +<sect1 id=scripts>Scripts +<p> + +All command scripts, including the package maintainer scripts inside +the package and used by <prgn/dpkg/, should have a <tt/#!/ line naming +the shell to be used to interpret them. +<p> + +In the case of Perl scripts this should be <tt>#!/usr/bin/perl</tt>. +<p> + +Shell scripts (<prgn/sh/ and <prgn/bash/) should almost certainly +start with <tt>set -e</> so that errors are detected. Every script +<em/must/ use <tt/set -e/ or check the exit status of <em/every/ +command. +<p> + +The standard shell interpreter `<tt>/bin/sh</tt>' may be a symbolic +link to any POSIX compatible shell. Thus, shell scripts specifying +`<tt>/bin/sh</tt>' as interpreter may only use POSIX features. If a +script requires non-POSIX features from the shell interpreter, the +appropriate shell has to be specified in the first line of the script +(e.g., `<tt>#!/bin/bash</tt>') and the package has to depend on the +package providing the shell (unless the shell package is marked +`Essential', e.g., in the case of <prgn/bash/). +<p> + +Restrict your script to POSIX features when possible so that it may +use <tt>/bin/sh</tt> as its interpreter. If your script works with +<prgn/ash/, it's probably POSIX compliant, but if you are in doubt, +use <tt>/bin/bash</tt>. +<p> + +Perl scripts should check for errors when making any system calls, +including <tt/open/, <tt/print/, <tt/close/, <tt/rename/ and +<tt/system/. +<p> + +<prgn/csh/ and <prgn/tcsh/ should be avoided as scripting languages. +See <em>Csh Programming Considered Harmful</>, one of the +<tt/comp.unix.*/ FAQs. It can be found on <ftpsite>rtfm.mit.edu</> in +<ftppath>/pub/usenet-by-group/comp.unix.programmer/Csh_Programming_Considered_Harmful</>. +If an upstream package comes with <prgn/csh/ scripts then you must +make sure that they start with <tt>#!/bin/csh</tt> and make your +package depend on the <prgn/c-shell/ virtual package. +<p> + +Any scripts which create files in world-writable directories (e.g., in +<tt>/tmp</tt>) have to use a mechanism which will fail if a file with +the same name already exists. +<p> + +The Debian base distribution provides the <prgn/tempfile/ and +<prgn/mktemp/ utilities for use by scripts for this purpose. +<p> + +<sect1>Symbolic links +<p> + +In general, symbolic links within a toplevel directory should be +relative, and symbolic links pointing from one toplevel directory into +another should be absolute. (A toplevel directory is a sub-directory +of the root directory `/'.) +<p> + +In addition, symbolic links should be specified as short as possible, +i.e., link targets like `foo/../bar' are deprecated. +<p> + +Note that when creating a relative link using <prgn/ln/ it is not +necessary for the target of the link to exist relative to the working +directory you're running <prgn/ln/ from; nor is it necessary to change +directory to the directory where the link is to be made. Simply +include the string that should appear as the target of the link (this +will be a pathname relative to the directory in which the link +resides) as the first argument to <prgn/ln/. +<p> + +For example, in your <prgn/Makefile/ or <tt>debian/rules</>, do things +like: +<example> + ln -fs gcc $(prefix)/bin/cc + ln -fs gcc debian/tmp/usr/bin/cc + ln -fs ../sbin/sendmail $(prefix)/bin/runq + ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq +</example> +<p> + +A symbolic link pointing to a compressed file should always have the +same file extension as the referenced file. (For example, if a file +`<tt>foo.gz</tt>' is referenced by a symbolic link, the filename of +the link has to end with `<tt>.gz</tt>' too, as in `bar.gz.') +<p> + +<sect1>Device files +<p> + +No package may include device files in the package file tree. +<p> + +If a package needs any special device files that are not included in +the base system, it has to call <prgn/makedev/ in the <tt/postinst/ +script, after asking the user for permission to do so. +<p> + +No package should remove any device files in the <tt/postrm/ or any +other script. This is left to the system administrator. +<p> + +Debian uses the serial devices <tt>/dev/tty*</tt>. Programs using the +old <tt>/dev/cu*</tt> devices should be changed to use +<tt>/dev/tty*</tt>. +<p> + +<sect1>Configuration files +<p> + +Any configuration files created or used by your package should reside +in <tt>/etc</tt>. If there are several you should consider creating a +subdirectory named after your package. +<p> + +It is almost certain that any file in <tt>/etc</tt> that is in your +package's filesystem archive should be listed in <prgn/dpkg/'s +<tt/conffiles/ control area file. (See the <em>Debian Packaging +Manual</em>). +<p> + +Only packages that are tagged <em/conflicting/ with each other may +specify the same file as <tt/conffile/. A package may not modify a +configuration file of another package. +<p> + +If two or more packages use the same configuration file, one of these +packages has to be defined as <em/owner/ of the configuration file, +i.e., it has to list the file as <tt/conffile/ and has to provide +a program that modifies the configuration file. +<p> + +The other packages have to depend on the <em/owner/ package and use +that program to update the configuration file. +<p> + +Sometimes it's appropriate to build a new package, which just provides +the basic <em/infrastructure/ for the other packages and which manages +the shared configuration files. (Check out the <prgn/sgml-base/ +package as an example.) +<p> + +Files in <tt>/etc/skel</> will automatically be copied into new user +accounts by <prgn/adduser/. They should not be referenced there by +any program. +<p> + +Therefore, if a program needs a dotfile to exist in advance in +<tt/$HOME/ to work sensibly that dotfile should be installed in +<tt>/etc/skel</> (and listed in conffiles, if it is not generated and +modified dynamically by the package's installation scripts). +<p> + +However, programs that require dotfiles in order to operate sensibly +(dotfiles that they do not create themselves automatically, that is) +are a bad thing, and programs should be configured by the Debian +default installation as close to normal as possible. +<p> + +Therefore, if a program in a Debian package needs to be configured in +some way in order to operate sensibly that configuration should be +done in a site-wide global configuration file elsewhere in +<tt>/etc</>. Only if the program doesn't support a site-wide default +configuration and the package maintainer doesn't have time to add it +should a default per-user file be placed in <tt>/etc/skel</>. +<p> + +<tt>/etc/skel</> should be as empty as we can make it. This is +particularly true because there is no easy mechanism for ensuring that +the appropriate dotfiles are copied into the accounts of existing +users when a package is installed. +<p> + +Ideally the sysadmin should not have to do any configuration other +than that done (semi-)automatically by the <tt/postinst/ script. +<p> + +<sect1>Permissions and owners +<p> + +The rules in this section are guidelines for general use. If +necessary you may deviate from the details below. However, if you do +so you must make sure that what is done is secure and you must try to +be as consistent as possible with the rest of the system. You should +probably also discuss it on <prgn/debian-devel/ first. +<p> + +Files should be owned by <tt/root.root/, and made writable only by +the owner and universally readable (and executable, if appropriate). +<p> + +Directories should be mode 755 or (for group-writability) mode 2775. +The ownership of the directory should be consistent with its mode--if +a directory is mode 2775, it should be owned by the group that needs +write access to it. +<p> + +Setuid and setgid executables should be mode 4755 or 2755 +respectively, and owned by the appropriate user or group. They should +not be made unreadable (modes like 4711 or 2711 or even 4111); doing +so achieves no extra security, because anyone can find the binary in +the freely available Debian package--it is merely inconvenient. For +the same reason you should not restrict read or execute permissions on +non-set-id executables. +<p> + +Some setuid programs need to be restricted to particular sets of +users, using file permissions. In this case they should be owned by +the uid to which they are set-id, and by the group which should be +allowed to execute them. They should have mode 4754; there is no +point in making them unreadable to those users who must not be allowed +to execute them. +<p> + +Do not arrange that the system administrator can only reconfigure the +package to correspond to their local security policy by changing the +permissions on a binary. Ordinary files installed by <prgn/dpkg/ (as +opposed to conffiles and other similar objects) have their permissions +reset to the distributed permissions when the package is reinstalled. +Instead you should consider (for example) creating a group for people +allowed to use the program(s) and making any setuid executables +executable only by that group. +<p> + +If you need to create a new user or group for your package there are +two possibilities. Firstly, you may need to make some files in the +binary package be owned by this user or group, or you may need to +compile the user or group id (rather than just the name) into the +binary (though this latter should be avoided if possible). In this +case you need a statically allocated id. +<p> + +You must ask for a user or group id from the base system maintainer, +and must not release the package until you have been allocated one. +Once you have been allocated one you must make the package depend on a +version of the base system with the id present in <tt>/etc/passwd</tt> +or <tt>/etc/group</tt>, or alternatively arrange for your package to +create the user or group itself with the correct id (using +<tt/adduser/) in its pre- or post-installation script (the latter is +to be preferred if it is possible). +<p> + +On the other hand, the program may able to determine the uid or gid +from the group name at runtime, so that a dynamic id can be used. In +this case you must choose an appropriate user or group name, +discussing this on <prgn/debian-devel/ and checking with the base +system maintainer that it is unique and that they do not wish you to +use a statically allocated id instead. When this has been checked you +must arrange for your package to create the user or group if necessary +using <prgn/adduser/ in the pre- or post-installation script (again, +the latter is to be preferred if it is possible). +<p> + +Note that changing the numeric value of an id associated with a name +is very difficult, and involves searching the filesystem for all +appropriate files. You need to think carefully whether a static or +dynamic id is required, since changing your mind later will cause +problems. +<p> + +<sect id="sysvinit">System run levels +<p> + +<sect1>Introduction +<p> + +The <tt>/etc/init.d</> directory contains the scripts executed by +<prgn/init/ at boot time and when init state (or `runlevel') is +changed (see <manref name=init section=8>). <p> + +These scripts are being referenced by symbolic links in the +<tt>/etc/rc<var/n/.d</> directories. When changing runlevels, +<prgn/init/ looks in the directory <tt>/etc/rc<var/n/.d</> for the +scripts it should execute, where <var/n/ is the runlevel that is being +changed to, or `S' for the boot-up scripts. <p> + +The names of the links all have the form <tt/S<var/mm/<var/script// or +<tt/K<var/mm/<var/script// where <var/mm/ is a two-digit number and +<var/script/ is the name of the script (this should be the same as the +name of the actual script in <tt>/etc/init.d</>. + +When <prgn/init/ changes runlevel first the targets of the links whose +names starting with a <tt/K/ are executed, each with the single +argument <tt/stop/, followed by the scripts prefixed with an <tt/S/, +each with the single argument <tt/start/. The <tt/K/ links are +responsible for killing services and the <tt/S/ link for starting +services upon entering the runlevel. +<p> + +For example, if we are changing from runlevel 2 to runlevel 3, init +will first execute all of the <tt/K/ prefixed scripts it finds in +<tt>/etc/rc3.d</>, and then all of the <tt/S/ prefixed scripts. The +links starting with <tt/K/ will cause the referred-to file to be +executed with an argument of <tt/stop/, and the <tt/S/ links with an +argument of <tt/start/. +<p> + +The two-digit number <var/mm/ is used to decide which order to start +and stop things in--low-numbered links have their scripts run first. +For example, the <tt/K20/ scripts will be executed before the <tt/K30/ +scripts. This is used when a certain service must be started before +another. For example, the name server <prgn/bind/ might need to be +started before the news server <prgn/inn/ so that <prgn/inn/ can set +up its access lists. In this case, the script that starts <prgn/bind/ +should have a lower number than the script that starts <prgn/inn/ so +that it runs first: +<example> + /etc/rc2.d/S17bind + /etc/rc2.d/S70inn +</example> + +<sect1>Writing the scripts +<p> + +Packages can and should place scripts in <tt>/etc/init.d</> to start +or stop services at boot time or during a change of runlevel. These +scripts should be named <tt>/etc/init.d/<var/package/</>, and they +should accept one argument, saying what to do: + +<taglist> +<tag><tt/start/ +<item>start the service, +<p> +<tag><tt/stop/ +<item>stop the service, +<p> +<tag><tt/restart/ +<item>stop and restart the service, +<p> +<tag><tt/reload/ +<item>cause the configuration of the service to be +reloaded without actually stopping and restarting the service, +<p> +<tag><tt/force-reload/ +<item>cause the configuration to be reloaded if the service supports +this, otherwise restart the service. +</taglist> + +The <tt/start/, <tt/stop/, <tt/restart/, and <tt/force-reload/ options +must be supported by all scripts in <tt>/etc/init.d</>, the +<tt/reload/ option is optional. +<p> + +The <tt/init.d/ scripts should ensure that they will behave sensibly +if invoked with <tt/start/ when the service is already running, or +with <tt/stop/ when it isn't, and that they don't kill +unfortunately-named user processes. The best way to achieve this is +usually to use <prgn/start-stop-daemon/. +<p> + +If a service reloads its configuration automatically (as in the case +of <prgn/cron/, for example), the <tt/reload/ option of the +<tt/init.d/ script should behave as if the configuration has been +reloaded successfully. +<p> + +These scripts should not fail obscurely when the configuration files +remain but the package has been removed, as the default in <prgn/dpkg/ +is to leave configuration files on the system after the package has +been removed. Only when it is executed with the <tt/--purge/ option +will dpkg remove configuration files. Therefore, you should include a +<tt/test/ statement at the top of the script, like this: +<example> + test -f <var/program-executed-later-in-script/ || exit 0 +</example> + +<sect1>Managing the links +<p> + +A program is provided, <prgn/update-rc.d/, to make it easier for +package maintainers to arrange for the proper creation and removal of +<tt>/etc/rc<var/n/.d</> symbolic links from their <tt/postinst/ and +<tt/postrm/ scripts. +<p> + +You should use this script to make changes to <tt>/etc/rc<var/n/.d</> +and <em/never/ include any <tt>/etc/rc<var/n/.d</> symbolic links in +the actual archive. +<p> + +By default <prgn/update-rc.d/ will start services in each of the +multi-user state runlevels (2, 3, 4, and 5) and stop them in the halt +runlevel (0), the single-user runlevel (1) and the reboot runlevel +(6). The system administrator will have the opportunity to customize +runlevels by simply adding, moving, or removing the symbolic links in +<tt>/etc/rc<var/n/.d</>. +<p> + +To get the default behaviour for your package, put in your +<tt/postinst/ script +<example> + update-rc.d <var/package/ default >/dev/null +</example> +and in your <tt/postrm/ +<example> + if [ purge = "$1" ]; then + update-rc.d <var/package/ remove >/dev/null + fi +</example> +<p> + +This will use a default sequence number of 20. If it does not matter +when or in which order the script is run, use this default. If it +does, then you should talk to the maintainer of the <prgn/sysvinit/ +package or post to <tt>debian-devel</>, and they will help you choose +a number. +<p> + +For more information about using <tt/update-rc.d/, please consult its +manpage <manref name=update-rc.d section=8>. +<p> + +<sect1>Boot-time initialisation +<p> + +There is another directory, <tt>/etc/rc.boot</>, which contains +scripts which are run once per machine boot. This facility is +provided for initialisation of hardware devices, cleaning up of +leftover files, and so forth. +<p> + +For example, the <prgn/kbd/ package provides a script here for +initialising the keyboard layout and console font and mode. +<p> + +The files in <tt>/etc/rc.boot</> should <em/not/ be links into +<tt>/etc/init.d</>--they should be the scripts themselves. +<p> + +<tt/rc.boot/ should <em/not/ be used for starting general-purpose +daemons and similar activities. This should be done using the +<tt/rc<var/n/.d/ scheme, above, so that the services can be started +and stopped cleanly when the runlevel changes or the machine is to be +shut down or rebooted. +<p> + +<sect1>Notes +<p> + +<em/Do not/ include the <tt>/etc/rc<var/n/.d/*</> symbolic links in +the <tt/.deb/ filesystem archive! <em/This will cause problems!/ +You should create them with <prgn/update-rc.d/, as above. +<p> + +<em/Do not/ include the <tt>/etc/rc<var/n/.d/*</> symbolic links in +<prgn/dpkg/'s conffiles list! <em/This will cause problems!/ <em/Do/, +however, include the <tt>/etc/init.d</> scripts in conffiles. (This +is important since we want to give the local system administrator the +chance to adapt the scripts to the local system--e.g., to disable a +service without deinstalling the package, or to specify some special +command line options when starting a service--while making sure her +changes aren't lost during the next package upgrade.) <p> + +<sect1>Example +<p> + +The <prgn/bind/ DNS (nameserver) package wants to make sure that the +nameserver is running in multiuser runlevels, and is properly shut +down with the system. It puts a script in <tt>/etc/init.d</>, naming +the script appropriately <tt/bind/. As you can see, the script +interprets the argument <tt/reload/ to send the nameserver a <tt/HUP/ +signal (causing it to reload its configuration); this way the user can +say <tt>/etc/init.d/bind reload</> to reload the name server. +<p> + +<example> + #!/bin/sh + # + # Original version by Robert Leslie <rob@mars.org>, edited by iwj and cs + + test -x /usr/sbin/named || exit 0 + + case "$1" in + start) + echo -n "Starting domain name service: named" + start-stop-daemon --start --quiet --exec /usr/sbin/named + echo "." + ;; + stop) + echo -n "Stopping domain name service: named" + start-stop-daemon --stop --quiet \ + --pidfile /var/run/named.pid --exec /usr/sbin/named + echo "." + ;; + restart) + echo -n "Restarting domain name service: named" + start-stop-daemon --stop --quiet \ + --pidfile /var/run/named.pid --exec /usr/sbin/named + start-stop-daemon --start --verbose --exec /usr/sbin/named + echo "." + ;; + force-reload|reload) + echo -n "Reloading configuration of domain name service: named" + start-stop-daemon --stop --signal 1 --quiet \ + --pidfile /var/run/named.pid --exec /usr/sbin/named + echo "." + ;; + *) + echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2 + exit 1 + ;; + esac + + exit 0 +</example> +<p> + +Another example on which to base your <tt>/etc/init.d</> scripts is in +<tt>/etc/init.d/skeleton</>. +<p> + +If this package is happy with the default setup from +<prgn/update-rc.d/, namely an ordering number of 20 and having named +running in all runlevels, it can say in its <tt/postinst/: +<example> + update-rc.d bind default >/dev/null +</example> +And in its <tt/postrm/, to remove the links when the package is purged: +<example> + if [ purge = "$1" ]; then + update-rc.d acct remove >/dev/null + fi +</example> +<p> + +<sect>Cron jobs +<p> + +Packages may not touch the configuration file <tt>/etc/crontab</>, nor +may they modify the files in <tt>/var/spool/cron/crontabs</>. +<p> + +If a package wants to install a job that has to be executed via +cron, it should place a file with the name if the package in one +of the following directories: +<example> + /etc/cron.daily + /etc/cron.weekly + /etc/cron.monthly +</example> +As these directory names say, the files within them are executed on +a daily, weekly, or monthly basis, respectively. +<p> + +If a certain job has to be executed more frequently than `daily,' the +package should install a file +<tt>/etc/cron.d/<package-name></tt> tagged as configuration +file. This file uses the same syntax as <tt>/etc/crontab</tt> and is +processed by <prgn/cron/ automatically. (Note, that scripts in the +<tt>/etc/cron.d</tt> directory are not handled by +<prgn/anacron/. Thus, you should only use this directory for jobs +which may be skipped if the system is not running.) +<p> + +All files installed in any of these directories have to be scripts +(shell scripts, Perl scripts, etc.) so that they can easily be +modified by the local system administrator. In addition, they have to +be registered as configuration file. +<p> + +The scripts in these directories have to check, if all necessary +programs are installed before they try to execute them. Otherwise, +problems will arise when a package was removed (but not purged), since +the configuration files are kept on the system in this situation. +<p> + +<sect>Console messages +<p> + +This section describes different formats for messages written to +standard output by the <tt>/etc/init.d</> scripts. The intent is to +improve the consistency of Debian's startup and shutdown look and +feel. +<p> + +Please look very careful at the details. We want to get the messages +to look exactly the same way concerning spaces, punctuation, and case +of letters. +<p> + +Here is a list of overall rules that you should use when you create output +messages. They can be useful if you have a non-standard message that isn't +covered in the sections below. +<p> + +<list> +<item> + Every message should cover one line, start with a capital letter and + end with a period `.'. +<p> + +<item> + If you want to express that the computer is working on something + (performing a specific task, not starting or stopping a program), we + use an ``ellipsis'', namely three dots `...'. Note that we don't insert + spaces in front of or behind the dots. + If the task has been completed we write `done.' and a line feed. +<p> + +<item> + Design your messages as if the computer is telling you what he is + doing (let him be polite :-) but don't mention ``him'' directly. + For example, if you think of saying +<example> + I'm starting network daemons: nfsd mountd. +</example> + just say +<example> + Starting network daemons: nfsd mountd. +</example> +</list> +<p> + +The following formats must be used +<p> + +<list> +<item> + when daemons get started. +<p> + + Use this format if your script starts one or more daemons. + The output should look like this (a single line, no leading spaces): +<example> + Starting <description>: <daemon-1> <daemon-2> <...> <daemon-n>. +</example> + The <description> should describe the subsystem the daemon or set of + daemons are part of, while <daemon-1> up to <daemon-n> + denote each daemon's name (typically the file name of the program). +<p> + + For example, the output of /etc/init.d/lpd would look like: +<example> + Starting printer spooler: lpd. +</example> +<p> + + This can be achieved by saying +<example> + echo -n "Starting printer spooler: lpd" + start-stop-daemon --start --quiet lpd + echo "." +</example> + in the script. If you have more than one daemon to start, you should + do the following: +<example> + echo -n "Starting remote filesystem services:" + echo -n " nfsd"; start-stop-daemon --start --quiet nfsd + echo -n " mountd"; start-stop-daemon --start --quiet mountd + echo -n " ugidd"; start-stop-daemon --start --quiet ugidd + echo "." +</example> + This makes it possible for the user to see what takes so long and when + the final daemon has been started. Please be careful where to put spaces: + In the example above the system administrator can easily comment out + a line if he don't wants to start a specific daemon, while the displayed + message still looks good. +<p> + +<item> + when something needs to be configured. +<p> + + If you have to set up different parameters of the system upon boot up, + you can use this format: +<example> + Setting <parameter> to `<value>'. +</example> +<p> + + You can use the following echo statement to get the quotes right: +<example> + echo "Setting DNS domainname to \`"value"'." +</example> +<p> + + Note that the left quotation mark (`) is different from the right ('). + +<item> + when a daemon is stopped. +<p> + + When you stop a daemon you should issue a message similar to the startup + message, except that `Starting' is replaced with `Stopping'. +<p> + + So stopping the printer daemon will like like this: +<example> + Stopping printer spooler: lpd. +</example> + +<item> + when something is executed. +<p> + + There a several examples where you have to run a program at system + startup or shutdown to perform a specific task. For example, setting + the system's clock via `netdate' or killing all processes when the + system comes down. Your message should like this: +<example> + Doing something very useful...done. +</example> + You should print the `done.' right after the job has been completed, + so that the user gets informed why he has to wait. You can get this + behaviour by saying +<example> + echo -n "Doing something very useful..." + do_something + echo "done." +</example> + in your script. + +<item> + when the configuration is reloaded. +<p> + + When a daemon is forced to reload its configuration files you +should use the following format: +<example> + Reloading <daemon's-name> configuration...done. +</example> + +<item> + when none of the above rules apply. +<p> + + If you have to print a message that doesn't fit into the styles described + above, you can use something appropriate, but please have a look at the + overall rules listed above. +</list> +<p> + +<sect>Menus +<p> + +The Debian <tt/menu/ packages provides a unique interface between +packages providing applications and documents, and <em/menu programs/ +(either X window managers or text-based menu programs as +<prgn/pdmenu/). +<p> + +All packages that provide applications that need not be passed any +special command line arguments for normal operation should register a +menu entry for those applications, so that users of the <tt/menu/ +package will automatically get menu entries in their window managers, +as well in shells like <tt/pdmenu/. +<p> + +Please refer to the <em>Debian Menu System</em> document that comes +with the <tt/menu/ package for information about how to register your +applications and web documents. +<p> + +<sect>Keyboard configuration +<p> + +To achieve a consistent keyboard configuration (i.e., all applications +interpret a keyboard event the same way) all programs in the Debian +distribution have to be configured to comply with the following +guidelines. +<p> + +Here is a list that contains certain keys and their interpretation: + +<taglist> +<tag><tt/<--/ +<item>delete the character to the left of the cursor +<p> +<tag><tt/Delete/ +<item>delete the character to the right of the cursor +<p> +<tag><tt/Control+H/ +<item>emacs: the help prefix +</taglist> + +The interpretation of any keyboard events should be independent of the +terminal that's used (either the console, X windows, rlogin/telnet +session, etc.). +<p> + +The following list explains how the different programs should be set +up to achieve this: +<p> + +<list compact> +<item>`<tt><--</tt>' generates KB_Backspace in X. +<p> +<item>`<tt/Delete/' generates KB_Delete in X. +<p> +<item>X translations are set up to make KB_Backspace generate ASCII DEL, + and to make KB_Delete generate <tt>ESC [ 3 ~</tt> (this is the vt220 escape + code for the `delete character' key). This must be done by loading + the resources using xrdb on all local X displays, not using the + application defaults, so that the translation resources used + correspond to the xmodmap settings. +<p> +<item>The Linux console is configured to make `<tt><--</tt>' generate DEL, and + `Delete' generate <tt>ESC [ 3 ~</tt> (this is the case at the moment). +<p> +<item>X applications are configured so that Backspace deletes left, and + Delete deletes right. Motif applications already work like this. +<p> +<item>stty erase <tt>^?</tt> . +<p> +<item>The `xterm' terminfo entry should have <tt>ESC [ 3 ~</tt> for kdch1, just + like TERM=linux and TERM=vt220. +<p> +<item>Emacs is programmed to map KB_Backspace or the `stty erase' + character to delete-backward-char, and KB_Delete or kdch1 to + delete-forward-char, and <tt>^H</tt> to help as always. +<p> +<item>Other applications use the `stty erase' character and kdch1 for the + two delete keys, with ASCII DEL being `delete previous character' + and kdch1 being `delete character under cursor'. +</list> +<p> + +This will solve the problem except for: +<p> + +<list compact> +<item>Some terminals have a <tt><--</tt> key that cannot be made to produce + anything except <tt>^H</tt>. On these terminals Emacs help will be + unavailable on <tt>^H</tt> (assuming that the `stty erase' character takes + precedence in Emacs, and has been set correctly). M-x help or F1 + (if available) can be used instead. +<p> +<item>Some operating systems use <tt>^H</tt> for stty erase. However, modern + telnet versions and all rlogin versions propagate stty settings, + and almost all UNIX versions honour stty erase. Where the stty + settings are not propagated correctly things can be made to work by + using stty manually. +<p> +<item>Some systems (including previous Debian versions) use xmodmap to + arrange for both <tt><--</tt> and Delete to generate KB_Delete). We can + change the behaviour of their X clients via the same X resources + that we use to do it for our own, or have our clients be configured + via their resources when things are the other way around. On + displays configured like this Delete will not work, but <tt><--</tt> will. +<p> +<item>Some operating systems have different kdch1 settings in their + terminfo for xterm and others. On these systems the Delete key + will not work correctly when you log in from a system conforming to + our policy, but <tt><--</tt> will. +</list> +<p> + +<sect>Environment variables +<p> + +No program may depend on environment variables to get reasonable +defaults. (That's because these environment variables would have to +be set in a system-wide configuration file like /etc/profile, which is +not supported by all shells.) +<p> + +If a program should depend on environment variables for its +configuration, the program has to be changed to fall back to a +reasonable default configuration if these environment variables are +not present. If this cannot be done easily (e.g., if the source code +of a non-free program is not available), the program should be +replaced by a small `wrapper' shell script which sets the environment +variables and calls the original program. +<p> + +Here is an example of a wrapper script for this purpose: + +<example> +#!/bin/sh +BAR=/var/lib/fubar +export BAR +exec /usr/lib/foo/foo "$@" +</example> +<p> + +Furthermore, as <tt>/etc/profile</tt> is a configuration file of the +<prgn/bash/ package, no other package may put any environment +variables or other commands into that file. +<p> + + + +<chapt>Customized programs +<p> + +<sect id="arch-spec">Architecture specification strings +<p> + +If a program needs to specify an <em>architecture specification +string</> in some place, the following format has to be used: +<example> + <arch>-linux +</example> +where `<arch>' is one of the following: i386, alpha, arm, m68k, +powerpc, sparc. +<p> + +Note, that we don't want to use `<arch>-debian-linux' to apply +to the rule `architecture-vendor-os' since this would make our +programs incompatible to other Linux distributions. Also note, that we +don't use `<arch>-unknown-linux', since the `unknown' does not +look very good. +<p> + +<sect>Daemons +<p> + +The configuration files <tt>/etc/services</tt>, +<tt>/etc/protocols</tt>, and <tt>/etc/rpc</tt> are managed by the +<prgn/netbase/ package and may not be modified by other packages. +<p> + +If a package requires a new entry in one of these files, the +maintainer has to get in contact with the <prgn/netbase/ maintainer, +who will add the entries and release a new version of the +<prgn/netbase/ package. +<p> + +The configuration file <tt>/etc/inetd.conf</tt> may be modified by the +package's scripts only via the <prgn/update-inetd/ script or the +<prgn/DebianNet.pm/ Perl module. +<p> + +If a package wants to install an example entry into +<tt>/etc/inetd.conf</tt>, the entry has to be preceded with exactly +one hash character (#). Such lines are treated as `commented out by +user' by the <prgn/update-inetd/ script and are not changed or +activated during a package updates. +<p> + +<sect>Editors and pagers +<p> + +Some programs have the ability to launch an editor or pager +program to edit or display a text document. Since there are +lots of different editors and pagers available in the Debian +distribution, the system administrator and each user should have +the possibility to choose his/her preferred editor and pager. +<p> + +In addition, every program should choose a good default +editor/pager if none is selected by the user or system +administrator. +<p> + +Thus, every program that launches an editor or pager has to use the +EDITOR or PAGER environment variables to determine the editor/pager +the user wants to get started. If these variables are not set, the +programs `/usr/bin/editor' and `/usr/bin/pager' have to be used, +respectively. +<p> + +These two files are managed through `alternatives.' That is, +every package providing an editor or pager has to call the +`update-alternatives' script to register these programs. +<p> + +If it is very hard to adapt a program to make us of the EDITOR +and PAGER variable, that program should be configured to use +`/usr/bin/sensible-editor' and `/usr/bin/sensible-pager' as +editor or pager program, respectively. These are two scripts +provided in the Debian base system that check the EDITOR and +PAGER variables and launches the appropriate program or +falls back to `/usr/bin/editor' and `/usr/bin/pager', +automatically. +<p> + +Since the Debian base system already provides an editor and +a pager program, there is no need for a package to depend on +`editor' and `pager', nor is it necessary for a package to +provide such virtual packages. +<p> + +<sect id="web-appl">Web servers and applications +<p> + +This section describes the locations and URLs that have to be used by +all web servers and web application in the Debian system. +<p> + +<enumlist> +<item>Cgi-bin executable files are installed in the directory +<example> + /usr/lib/cgi-bin/<cgi-bin-name> +</example> +and can be referred to as +<example> + http://localhost/cgi-bin/<cgi-bin-name> +</example> +<p> + +<item>Access to html documents +<p> + +Html documents for a package are stored in /usr/doc/<package> and can be +referred to as +<example> + http://localhost/doc/<package>/<filename> +</example> +<p> + +<item>Web Document Root +<p> + +Web Applications should try to avoid storing files in the Web Document Root. +Instead use the /usr/doc/<package> directory for documents and +register the Web Application via the menu package. If access to the +web-root is unavoidable then use +<example> + /var/www +</example> +as the Document Root. This might be just a symbolic link to the location where the +sysadmin has put the real document root. +<p> + +</enumlist> +<p> + +<sect>Mail transport agents +<p> + +Debian packages which process electronic mail, whether +mail-user-agents (MUAs) or mail-transport-agents (MTAs), <em/must/ +make sure that they are compatible with the configuration decisions +below. Failure to do this may result in lost mail, broken <tt/From:/ +lines, and other serious brain damage! +<p> + +The mail spool is <tt>/var/spool/mail</> and the interface to send a +mail message is <tt>/usr/sbin/sendmail</> (as per the FSSTND). The +mail spool is part of the base system and not part of the MTA package. +<p> + +All Debian MUAs and MTAs have to use the <tt>maillock</tt> and +<tt>mailunlock</tt> functions provided by the <tt>liblockfile</tt> +packages to lock and unlock mail boxes. These functions implement +a NFS-safe locking mechanism. (It is ok if MUAs and MTAs don't link +against liblockfile but use a <em/compatible/ mechanism. Please +compare the mechanisms very carefully!) +<p> + +Mailboxes are generally 660 <tt/<var/user/.mail/ unless the user has +chosen otherwise. A MUA may remove a mailbox (unless it has +nonstandard permissions) in which case the MTA or another MUA must +recreate it if needed. Mailboxes must be writable by group mail. +<p> + +The mail spool is 2775 <tt/mail.mail/, and MUAs need to be setgid +mail to do the locking mentioned above (and obviously need to avoid +accessing other users' mailboxes using this privilege). +<p> + +<tt>/etc/aliases</> is the source file for the system mail aliases +(e.g., postmaster, usenet, etc.)--it is the one which the sysadmin +and <tt/postinst/ scripts may edit. After <tt>/etc/aliases</> is edited +the program or human editing it must call <prgn/newaliases/. All MTA +packages should come with a <prgn/newaliases/ program, even if it does +nothing, but older MTA packages do not do this so programs should not +fail if <prgn/newaliases/ cannot be found. +<p> + +The convention of writing <tt/forward to <var/address// in the mailbox +itself is not supported. Use a <tt/.forward/ file instead. +<p> + +The location for the <prgn/rmail/ program used by UUCP for incoming +mail is <tt>/usr/sbin/rmail</>, as per the FSSTND. Likewise, +<prgn/rsmtp/, for receiving batch-SMTP-over-UUCP, is in +<tt>/usr/sbin/rsmtp</> if it is supported. +<p> + +If you need to know what name to use (for example) on outgoing news +and mail messages which are generated locally, you should use the file +<tt>/etc/mailname</>. It will contain the portion after the username +and <tt/@/ (at) sign for email addresses of users on the machine +(followed by a newline). +<p> + +A package should check for the existence of this file. If it exists +it should use it without comment. (An MTA's prompting +configuration script may wish to prompt the user even if it finds this +file exists.) If it does not exist it should prompt the user +for the value and store it in <tt>/etc/mailname</> as well as using it +in the package's configuration. The prompt should make it clear that +the name will not just be used by that package. For example, in this +situation the INN package says: +<example> + Please enter the `mail name' of your system. This is the hostname + portion of the address to be shown on outgoing news and mail messages. + The default is <var/syshostname/, your system's host name. + Mail name [`<var/syshostname/']: +</example> +where <var/syshostname/ is the output of <tt/hostname --fqdn/. +<p> + +<sect>News system configuration +<p> + +All the configuration files related to the NNTP (news) servers and +clients should be located under <tt>/etc/news</tt>. +<p> + +There are some configuration issues that apply to a number of +news clients and server packages on the machine. These are: + +<taglist> +<tag>/etc/news/organization +<item>A string which shall appear as the + organization header for all messages posted + by NNTP clients on the machine +<p> +<tag>/etc/news/server +<item>Contains the FQDN of the upstream NNTP + server, or localhost if the local machine is + an NNTP server. +</taglist> + +Other global files may be added as required for cross-package news +configuration. +<p> + +<sect>Programs for the X Windows system +<p> + +Some programs can be configured with or without support for X Windows. +Typically these binaries produced when configured for X will need the +X shared libraries to run. +<p> + +Such programs should be configured <em/with/ X support, and should +declare a dependency on <tt/xlib6g/ (for the X11R6 libraries). +Users who wish to use the program can install just the relatively +small <tt/xlib6g/ package, and do not need to install the whole of X. +<p> + +Do not create two versions (one with X support and one without) of +your package. +<p> + +<em>Application defaults</em> files have to be installed in the +directory <tt>/usr/X11R6/lib/X11/app-defaults/</tt>. They are +considered as part of the program code. Thus, they should not be +modified and should not be tagged as <em>conffile</em>. If the local +system administrator wants to customise X applications globally, the +file <tt>/etc/X11/Xresources</tt> should be used. +<p> + +If you package a program that requires a non-free Motif library, it +would be good if you can provide a "foo-smotif" and a "foo-dmotif" +package, containing a (against Motif libraries) statically and a +dynamically linked version, respectively. This way, users without +Motif can use the package too, while users that have Motif installed +get the advantages of a dynamically linked version. +<p> + +However, if your package works reliably with lesstif, you should +package it with lesstif, and not with Motif at all. +<p> + +Note, that packages that require non-free Motif libraries can't go +into the main section. If your package is free otherwise, it should go +into contrib. Otherwise it has to go into non-free. +<p> + +<sect>Emacs lisp programs +<p> + +Please refer to the `Debian Emacs Policy' (documented in +<tt>debian-emacs-policy.gz</tt> of the <prgn/emacsen-common/ package) +for details of how to package emacs lisp programs. +<p> + +<sect>Games +<p> + +The permissions on /var/lib/games are 755 <tt/root.root/. +<p> + +Each game decides on its own security policy. +<p> + +Games which require protected, privileged access to high-score files, +savegames, etc., must be made set-<em/group/-id (mode 2755) and +owned by <tt/root.games/, and use files and directories with +appropriate permissions (770 <tt/root.games/, for example). They must +<em/not/ be made set-<em/user/-id, as this causes security +problems. (If an attacker can subvert any set-user-id game +they can overwrite the executable of any other, causing other players +of these games to run a Trojan horse program. With a set-group-id +game the attacker only gets access to less important game data, and if +they can get at the other players' accounts at all it will take +considerably more effort.) +<p> + +Some packages, for example some fortune cookie programs, are +configured by the upstream authors to install with their data files or +other static information made unreadable so that they can only be +accessed through set-id programs provided. Do not do this in a Debian +package: anyone can download the <tt/.deb/ file and read the data from +it, so there is no point making the files unreadable. Not making the +files unreadable also means that you don't have to make so many +programs set-id, which reduces the risk of a security hole. +<p> + +As described in the FSSTND, binaries of games should be installed in +the directory <tt>/usr/games</tt>. This also applies to games that use +the X windows system. Manual pages for games (X and non-X games) should +be installed in <tt>/usr/man/man6</tt>. +<p> + +<chapt>Documentation +<p> + +<sect>Manual pages +<p> + +You must install manual pages in <prgn/nroff/ source form, in appropriate +places under <tt>/usr/man</tt>. You should only use sections 1 to 9 +(see the FSSTND for more details). You must <em/not/ install a +preformatted `cat page'. +<p> + +If no manual page is available for a particular program, utility or +function and this is reported as a bug on debian-bugs, a symbolic link +from the requested manual page to the <manref name=undocumented +section=7> manual page should be provided. This symbolic link can be +created from <tt>debian/rules</> like this: +<example> + ln -s ../man7/undocumented.7.gz \ + debian/tmp/usr/man/man[1-9]/the_requested_manpage.[1-9].gz +</example> +This manpage claims that the lack of a manpage has been reported as a +bug, so you may only do this if it really has (you can report it +yourself, if you like). Do not close the bug report until a proper +manpage is available. +<p> + +You may forward a complaint about a missing manpage to the upstream +authors, and mark the bug as forwarded in the Debian bug tracking +system. Even though the GNU Project do not in general consider the +lack of a manpage to be a bug, we do--if they tell you that they +don't consider it a bug you should leave the bug in our bug tracking +system open anyway. +<p> + +Manual pages should be installed compressed using <tt/gzip -9/. +<p> + +If one manpage needs to be accessible via several names it is better +to use a symbolic link than the <tt/.so/ feature, but there is no need +to fiddle with the relevant parts of the upstream source to change +from <tt/.so/ to symlinks--don't do it unless it's easy. Do not +create hard links in the manual page directories, and do not put +absolute filenames in <tt/.so/ directives. The filename in a <tt/.so/ +in a manpage should be relative to the base of the manpage tree +(usually <tt>/usr/man</tt>). +<p> + +<sect>Info documents +<p> + +Info documents should be installed in <tt>/usr/info</tt>. They should +be compressed with <tt/gzip -9/. +<p> + +Your package must call <prgn/install-info/ to update the Info <tt/dir/ +file, in its post-installation script: +<example> + install-info --quiet --section Development Development \ + /usr/info/foobar.info +</example> +<p> + +It is a good idea to specify a section for the location of your +program; this is done with the <tt/--section/ switch. To determine +which section to use, you should look at <tt>/usr/info/dir</> on your +system and choose the most relevant (or create a new section if none +of the current sections are relevant). Note that the <tt/--section/ +flag takes two arguments; the first is a regular expression to match +(case-insensitively) against an existing section, the second is used +when creating a new one. +<p> + +You must remove the entries in the pre-removal script: +<example> + install-info --quiet --remove /usr/info/foobar.info +</example> +<p> + +If <prgn/install-info/ cannot find a description entry in the Info +file you will have to supply one. See <manref name=install-info +section=8> for details. +<p> + +<sect>Additional documentation +<p> + +Any additional documentation that comes with the package can be +installed at the discretion of the package maintainer. Text +documentation should be installed in a directory +<tt>/usr/doc/<var/package/</tt>, where <var/package/ is the +name of the package, and compressed with <tt/gzip -9/ +unless it is small. +<p> + +If a package comes with large amounts of documentation which many +users of the package will not require you should create a separate +binary package to contain it, so that it does not take up disk space +on the machines of users who do not need or want it installed. +<p> + +It is often a good idea to put text information files (<tt/README/s, +changelogs, and so forth) that come with the source package in +<tt>/usr/doc/<var/package/</> in the binary package. However, you don't +need to install the instructions for building and installing the package, of +course! +<p> + +<sect>Preferred documentation formats +<p> + +The unification of Debian documentation is being carried out via HTML. +<p> + +If your package comes with extensive documentation in a markup format +that can be converted to various other formats you should if possible +ship HTML versions in the binary package, in the directory +<tt>/usr/doc/<var/package/</> or its subdirectories. +<p> + +Other formats such as PostScript may be provided at your option. +<p> + +<sect>Log files +<p> + +Log files should usually be named <tt>/var/log/<var/package/.log</tt>. +If you have many log files, or need a separate directory for +permissions reasons (<tt>/var/log</tt> is writable only by +<tt/root/), you should usually create a directory named +<tt>/var/log/<var/package/</tt>. +<p> + +Make sure that any log files are rotated occasionally so that they +don't grow indefinitely; the best way to do this is to use +<prgn/savelog/ program in an <tt>/etc/cron.daily</>, +<tt>/etc/cron.weekly</> or <tt>/etc/cron.monthly</> script. Here is a good +example: +<example> + [ -d /var/log/apache/. ] || exit 0 + umask 022 + cd /var/log/apache + if [ -fs access.log ] + then + savelog -c 7 access.log > /dev/null + fi +</example> +<p> + +Make sure that any log files are removed when the package is purged +(but not when it is only removed), by checking the argument to the +<tt/postrm/ script (see the <em>Debian Packaging Manual</em> for +details). +<p> + +<sect id="copyrightfile">Copyright information +<p> + +Every package must be accompanied by a verbatim copy of its copyright +and distribution license in the file +/usr/doc/<package-name>/copyright. This file must neither be +compressed nor be a symbolic link. +<p> + +In addition, the copyright file must say where the upstream sources +(if any) were obtained, and explain briefly what modifications were +made in the Debian version of the package compared to the upstream +one. It must name the original authors of the package and the Debian +maintainer(s) who were involved with its creation. +<p> + +/usr/doc/<package-name> may be a symbolic link to a directory in +/usr/doc only if two packages both come from the same source and the +first package has a "Depends" relationship on the second. These rules +are important because copyrights must be extractable by mechanical +means. +<p> + +Packages distributed under the UCB BSD license, the Artistic license, +the GNU GPL, and the GNU LGPL should refer to the files +/usr/doc/copyright/BSD, /usr/doc/copyright/Artistic, +/usr/doc/copyright/GPL, and /usr/doc/copyright/LGPL. +<p> + +Do not use the copyright file as a general <tt/README/ file. If your +package has such a file it should be installed in +<tt>/usr/doc/<var/package//README</> or <tt/README.Debian/ or some +other appropriate place. +<p> + +<sect>Examples +<p> + +Any examples (configurations, source files, whatever), should be +installed in a directory <tt>/usr/doc/<var/package//examples</tt>. +These files should not be referenced by any program--they're there +for the benefit of the system administrator and users, as +documentation only. +<p> + +<sect id="instchangelog">Changelog files +<p> + +This installed file must contain a copy of the <tt>debian/changelog</> +file from your Debian source tree, and a copy of the upstream +changelog file if there is one. They should usually be installed in +<tt>/usr/doc/<var/package/</> as <tt/changelog.Debian.gz/ and +<tt/changelog.gz/ respectively. +<p> + +Both should be installed compressed using <tt/gzip -9/, as they will +become large with time even if they start out small. +<p> + +If the package has only one changelog which is used both as the Debian +changelog and the upstream one because there is no separate upstream +maintainer then that changelog should usually be installed as +<tt>/usr/doc/<var/package//changelog.gz</>; if there is a separate +upstream maintainer, but no upstream changelog, then the Debian +changelog should still be called <tt/changelog.Debian.gz/. +<p> + +</book> diff --git a/upgrading-checklist.html b/upgrading-checklist.html new file mode 100644 index 0000000..13aed5d --- /dev/null +++ b/upgrading-checklist.html @@ -0,0 +1,164 @@ +<html><head><title>Policy checklist for upgrading your packages + + +

Policy checklist for upgrading your packages

+ +

About the checklist

+ +The checklist below has been created to simplify the upgrading process +of old packages. Note, that this list is not `official.' If you have +doubts about a certain topic, if you need more details, or if you +think some other package does not comply with policy, please refer to +the Policy Manual. +

+ +Here is how the check list works: Check out which policy version your +packages complies with currently. Than move upwards until the top and +check which of the items on the list might concern your package. If an +item does not give you enough details, please check out the Policy +Manual. +

+ +

The checklist

+ +
+
+2.4.1.0                         Apr 98
+
+  Policy Manual:
+    - Updated section 3.3.5 Symbolic links:
+      + symbolic links within a toplevel directory should be relative,
+        symbolic links between toplevel directories should be absolute
+        (cf., Policy Weekly Issue#6, topic 2)
+
+    - Updated section 4.9 Games:
+      + manpages for games should be installed in /usr/man/man6
+        (cf., Policy Weekly Issue#6, topic 3)
+
+  Packaging Manual:
+    - Updated prefix of chapter 12, Shared Libraries:
+      ldconfig must be called in the postinst script if the package
+      installs shared libraries
+      (cf., Policy Weekly Issue #6, fixes:bug#20515)
+  
+2.4.0.0                         Jan 98
+
+    - Updated section 3.3.4 Scripts:
+      + /bin/sh may be any POSIX compatible shell
+      + scripts including bashisms have to specify /bin/bash as
+        interpreter
+      + scripts which create files in world-writable directories
+        (e.g., in /tmp) should use tempfile or mktemp for creating
+        the directory
+
+    - Updated section 3.3.5 Symbolic Links:
+      + symbolic links referencing compressed files must have the same
+        file extension as the referenced file
+
+    - Updated section 3.3.6 Device files:
+      + /dev/tty* serial devices should be used instead of /dev/cu*
+
+    - Updated section 3.4.2 Writing the scripts [in /etc/init.d]:
+      + all /etc/init.d scripts have to provide the following options:
+        start, stop, restart, force-reload
+      + the reload option is optional and must never stop and restart
+        the service
+
+    - Updated section 3.5 Cron jobs:
+      + cron jobs that need to be executed more often than daily should
+        be installed into /etc/cron.d
+
+    - Updated section 3.7 Menus:
+      + removed section about how to register HTML docs to `menu'
+        (the corresponding section in 4.4, Web servers and applications,
+        has been removed in policy 2.2.0.0 already, so this one was
+        obsolete)
+
+    - New section 3.8 Keyboard configuration:
+      + details about how the backspace and delete keys should be
+        handled
+
+    - New section 3.9 Environment variables:
+      + no program must depend on environment variables to get a
+        reasonable default configuration
+
+    - New section 4.6 News system configuration:
+      + /etc/news/organization and /etc/news/server should be supported
+        by all news servers and clients
+
+    - Updated section 4.7 Programs for the X Windows system:
+      + programs requiring a non-free Motif library should be provided
+        as foo-smotif and foo-dmotif package
+      + if lesstif works reliably for such program, it should be linked
+        against lesstif and not against a non-free Motif library
+
+    - Updated section 4.9 Games:
+      + games for X Windows have to be installed in /usr/games, just as
+        non-X games
+
+2.3.0.1, 2.3.0.0		Sep 97
+
+	* new section `4.2 Daemons' including rules for
+	  /etc/services, /etc/protocols, /etc/rpc, and /etc/inetd.conf
+
+	* updated section about `Configuration files':
+	  packages may not touch other packages' configuration files  
+
+	* MUAs and MTAs have to use liblockfile
+
+2.2.0.0				Jul 97
+
+	* added section 4.1 `Architecture specification strings':
+          use
+	       <arch>-linux 
+          where <arch> is one of the following:
+               i386, alpha, arm, m68k, powerpc, sparc.
+
+	* detailed rules for /usr/local
+
+	* user ID's
+
+	* editor/pager policy
+
+	* cron jobs
+
+	* device files
+
+	* don't install shared libraries as executable
+
+	* app-defaults files may not be conffiles
+
+2.1.3.2, 2.1.3.1, 2.1.3.0	Mar 97
+
+	* two programs with different functionality must not have the
+	  same name
+
+	* "Webstandard 3.0"
+
+	* "Standard for Console Messages"
+
+	* Libraries should be compiled with `-D_REENTRANT'
+
+	* Libraries should be stripped with "strip --strip-unneeded"
+
+2.1.2.2, 2.1.2.1, 2.1.2.0	Nov 96
+
+	* Some changes WRT shared libraries
+
+2.1.1.0				Sep 96
+
+	* No hard links in source packages
+	
+	* Do not use dpkg-divert or update-alternatives without consultation
+
+	* Shared libraries must be installed stripped
+
+2.1.0.0				Aug 96
+
+	* Upstream changelog must be installed too
+
+ +

+

+ + diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt new file mode 100644 index 0000000..c01cd6b --- /dev/null +++ b/virtual-package-names-list.txt @@ -0,0 +1,135 @@ + + AUTHORITATIVE LIST OF VIRTUAL PACKAGE NAMES + + Apr 1998, 14 + + +Below is an authoritative list of virtual package names currently +in-use or proposed and not objected to. Please check the list below +for things relevant to your packages. + +New packages MUST use virtual package names where appropriate (this +includes making new ones - read on). + +Packages MUST NOT use virtual package names (except privately, amongst +a cooperating group of packages) unless they have been agreed upon and +appear in this list. + +The latest version of this file can be found in + doc/package-developer/virtual-package-names-list.text +on your local Debian FTP site. + +The procedure for updating the list is as follows: + +1. Post to debian-devel saying what names you intend to use or what + other changes you wish to make. + +2. Wait a few days for comment. + +3. Mail the maintainer of the virtual package name list (Christian + Schwarz ) notifying him of the consensus reached (or + your suggestions if noone objected). Please include a proposed brief + description of the new virtual name(s) for the list. The list + maintainer will then post the new list to debian-devel and upload it + to the FTP site. + +4. Go and use the new or changed names. + +Chris. +(based on earlier version by Warwick and Ian Jackson) + + +Now, the list: + +X Windows +--------- +xserver Any X server (used by other X packages) + +Miscellaneous +------------- +libc.so.4 An a.out shared C library, version 4.x.x. +info-browser Something that can browser GNU Info files +kernel-source Kernel source code +kernel-headers Kernel header files (, ) +kernel-image Kernel image (vmlinuz, System.map, modules) +httpd Any HTTP server +postscript-viewer Anything that can display Postscript files +postscript-preview Any preprocessor that creates Postscript output +www-browser Something that can browse html files +awk Anything providing suitable /usr/bin/{awk,nawk} +c-shell Anything providing a suitable /usr/bin/csh +pdf-viewer Anything that can display PDF files +pdf-preview Any preprocessor that creates PDF output +wordlist Anything that provides /usr/dict/words +dotfile-module Anything that provides a module for the + Dotfile Generator +ups-monitor Anything that is capable of controlling an UPS +tclsh Anything that provides /usr/bin/tclsh +wish Anything that provides /usr/bin/wish +c-compiler Anything providing a C compiler +fortran77-compiler Anything providing a Fortran77 compiler +lambdamoo-core A lambdamoo-compatible datebase package +lambdamoo-server Anything running a moo using a lambdamoo-core +libc-dev Anything that provides header and object files + of `libc' +emacsen Anything providing the GNU emacs or a compatible + editor + +News and Mail +------------- +mail-transport-agent Mail transport agents (Smail, Sendmail, &c) +mail-reader Mail user agents (Pine, Elm, mailx, &c) +news-transport-system Local news system (INN, C News or B News) +news-reader Any news reader (trn, tin, &c) +pgp A version of PGP (International or US) +imap-client Any mail reader capable of accessing remote mail + folders using the IMAP protocol (e.g. Pine) +imap-server Any IMAP mail server + +Old and obsolete virtual package names +-------------------------------------- +Note, that no other package then the ones listed here should use +these virtual package names. + +X11R5 provided by xcompat for compatibility reasons +xr5shlib do. +aout-x11r6lib do. +X11R6 do. + + +Changelog +--------- + +Ian Jackson: + 22 Sep 1995 Initial revision. + +Andrew Howell: + 26 Mar 1996 Added www-browser. + +Manoj Srivastava + 11 May 1996 Added kernel-image, added new location of this file + +Warwick Harvey: + 19 May 1996 Took over maintenance of list, changed instructions for + updating list + 25 Jul 1996 Added awk as per Chris Fearnley's suggestion + Added c-shell, which seemed to have dropped off at some stage + 2 Aug 1996 Added pdf-{viewer,preview}, compress, emacs + 5 Aug 1996 Added imap-{client,server} + 8 Aug 1996 Added editor + 20 Aug 1996 Added sgmls, removed metafont, dvilj, dvips + 25 Nov 1996 Removed editor (should have done this a long time ago) + +Christian Schwarz + 29 Apr 1997 New maintainer of this list + 5 May 1997 Added wordlist + 29 May 1997 Added dotfile-module, ups-monitor, tcl-interpreter, + tk-interpreter + 21 Jun 1997 Removed obsolete virtual packages: xR6shlib, xlibraries, + compress, emacs, sgmls, inews, gs_x, gs_svga, gs_both, xpmR6 + Added new section about obsolete names + 1 Sep 1997 Renamed `tcl/tk-interpreter' to `tclsh/wish' + 21 Oct 1997 Added emacs, c-compiler, fortran77-compiler, lambdamoo-core, + lambdamoo-server + 29 Jan 1998 Added libc-dev, emacsen + 14 Apr 1998 Removed obsolete virtual package `emacs' -- 2.39.5