From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 14 Sep 2002 04:37:04 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 323 ************************************************** Friday 13 September 2002 Number 323 ************************************************** Subjects for today 1 Final FHS : Andreas Buening 2 Re: Final FHS : Mentore Siesto 3 Re: Final FHS : Andreas Buening 4 Re: Final FHS : Andreas Buening 5 Re: Final FHS : IanM" 6 FTP access for package maintainers : IanM" **= Email 1 ==========================** Date: Sat, 14 Sep 2002 02:16:29 +0200 From: Andreas Buening Subject: Final FHS Hello! I've just finished the updated filesystem hierarchy for UnixOS/2. The document is not complete in the sense that all sections have been filled with text but I guess I've now included all stuff that is relevant for UnixOS/2 (and also some stuff that is most likely irrelevant). If you have anything to mention about this standard then speak now or be silent forever. ;-) Ian, if there are no severe objections against this document, could you put it on the UnixOS/2 webpage? I'm thinking about something like 1. Goals of the UnixOS/2 project 2. Requirements 3. Directory structure -> this document 4. How to build a package 5. How to install a package 6. ... so that we have a written documentation instead a list of more or less archived mails. :-) -------------------------------------------- ***** UnixOS/2 Filesystem Hierarchy Standard 1.0 ***** (based on FHS Version 2.2, available at http://www.pathname.com/fhs) All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Copyright (c) 1994-2001 Daniel Quinlan Copyright (c) 2001 Paul 'Rusty' Russel Copyright (c) 2002 Andreas Buening (adaption to UnixOS/2) Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserverd an all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy an distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. 1. Introduction ... 2. The Filesystem In the following sections the term "root filesystem" represents the top level directory of the filesystem that is defined by the drive letter of the UNIXROOT environment variable. It is not recommended but the root filesystem may be TVFS. In this case it's in the responsibility of the local system administrator to provide all necessary directories and all necessary read and write permissions to the mounted filesystems for the UnixOS/2 distribution. The UnixOS/2 distribution requires the following environment variables: UNIXROOT, TMPDIR, HOME, CONFIG_SITE (optional) ... 3. The Root Filesystem/var/account Process accounting logs (optional) 3.1 Purpose The contents of the root filesystem must be adequate to restore, recover, and/or repair the system. ... 3.2 Requirements The following directories are required in /: /bin Essential command binaries /etc Host-specific system configuration /lib Essential shared libraries /opt Add-on application software packages /sbin Essential system binaries /usr Secondary hierarchy /var Variable data Unlike on Unix systems temporary files have to be stored into $TMPDIR instead of /tmp. The other Unix directories /boot, /dev and /root have currently no meaning for UnixOS/2 and do not exist. Each directory listed above is specified in detail in separate subsections below. /usr and /var each have a complete section in this document due to the complexity of those directories. 3.3 Specific Options The following directories must be in /, if the corresponding subsystem is installed: /home User home directories (optional) /lib Alternate format essential shares libraries (optional) /mnt Mount point for mounting a filesystem temporarily Each directory listed above is specified in detail in separate subsections below. 3.4 /bin: Essential user command binaries (for use by all users) 3.4.1 Purpose /bin contains commands that may be used by both the system administrator and by users, but which are required to maintain, install or repair an existing UnixOS/2 installation or to install or remove binary packages. It may also contain commands which are used indirectly by scripts. /bin may be the first directory entry in PATH. 3.4.2 Requirements There must be no subdirectories in /bin. The following commands are required in /bin (note: if the FHS standard requires a command like cp or mv to be in /bin I added the whole GNU file utiltiy package to /bin to minimize maintainance effort): GNU file utilities GNU shell utilities GNU text utilities grep installpkg more removepkg sed sh The Bourne command shell (currently pdksh) unzip ux2-package, ux2-update, ux2-check (currently these are only placeholders) zip 3.4.3 Specific Options The following programs must be in /bin is the corresponding subsystem is installed: csh ed tar cpio gzip gunzip zcat netstat ping bzip2 bunzip2 (To be exactly I think we will not need csh, ed, netstat and ping here, but at least all programs that are required to install or repair or remove packages) 3.5 /etc: Host-specific system configuration 3.5.1 Purpose /etc contains configuration files and directories that are specific to the current system. 3.5.2 Requirements No binaries may be located under /etc. The following directories are required in /etc: /etc/opt Configuration for /opt /etc/unixos2 Configuration for the UnixOS/2 distro. Host-specific configuration files for software packages that are installed in /usr or /usr/local must be installd within the directoriy /etc/, where is the name of the subtree in /opt where the static data from the package is stored. 3.5.3 Specific Options The following directories must be in /etc if the corresponding subsystem is installed: /etc/X11 Configuration for the X Window System (optional) /etc/sgml Configuration for SGML and XML (optional) The following files must be in /etc if the corresponding subsystem is installed: Currently none. 3.5.4 /etc/opt: Configuration files for /opt 3.5.4.1 Purpose Host-specific configuration files for add-on application software packages must be installed within the directoriy /etc/opt/, where is the name of the subtree in /opt where the static data from the package is stored. 3.5.4.2 Requirements No structure is imposed on the internal arrangement of /etc/opt/. If a configuration file must reside in a different location in order for the package or system to function properly, it may be placed in a location other than /etc/opt/. 3.5.5 /etc/unixos2: Configuration files for the UnixOS/2 distro 3.5.5.1 Purpose /etc/unixos2 is the location for all UnixOS/2 host-specific configuration. 3.5.5.2 Specific Options The folling files must be in /etc/unixos2 if the corresponding subsystem is installed: config.site Configuration for configure scripts (optional) If config.site exists the environment variable CONFIG_SITE must point to config.site. (maybe we can also put manpath.config and other files here) 3.5.6 /etc/X11: Configuration for the X Window System (optional) 3.5.6.1 Purpose /etc/X11 is the location for all X11 host-specific configurations. This directory is necessary to allow local control if /usr is mounted read only. 3.5.6.2 Specific Options The following files must be in /etc/X11 if the corresponding subsystem is installed: Xconfig The configuration file for early versions of XFree86 (optional) XF86Config The configuration file for XFree86 version 3 and 4 (optional) Xmodmap Global X11 keyboard modification file (optional) Subdirectories of /etc/X11 may include those for xdm and for any other programs (some window managers, for example) that need them. We recommend that window managers with only one configuration file which is a default .*wmrc file must name it system.*wmrc (unless there is a widely-accepted alternative name) and not use a subdirectory. Any window manager subdirectories must be identically named to the actual window manager binary (without trailing ".exe" suffix). 3.5.7 /etc/sgml: Configuration files for SGML and XML (optional) 3.5.6.1 Purpose Generic configuration files defining high-level parameters of the SGML or XML systems are installed here. Files with names *,conf indicate generic configuration files. File names with *.cat are DTD-specific centralized catalogs, containing references to all other catalogs needed to use the given DTD. The super catalog file catalog references all the centralized catalogs. 3.6 /home: User home directories (optional) 3.6.1 Purpose /home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Therefore, no program should rely on this location. The environment variable HOME specifies the current user's home directory. /home may be on a filesystem different from UNIXROOT. 3.7 /lib: Essential shared libraries 3.7.1 Purpose The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin. /lib may be the first directory entry in LIBPATH. 3.7.2 Requirements The following files are required in /lib: charset.alias charset alias table for gettext emxio.dll emx dlls (have I forgotten any?) emxlibc.dll emxlibcm.dll emxlibcs.dll emxwrap.dll intl.dll GNU gettext library ux2emx.dll UnixOS/2 extensions for emx (if anybody has a better name for it, please tell me) ux2util.dll REXX dll required by installpkg/removepkg To minimize the maintainance effort the according static and import libraries may be installed either in /lib or in /usr/lib. The iconv libraries must be installed in /usr/lib because intl.dll has to linked statically with iconv and none of the programs in /bin and /sbin may require iconv.dll or iconv2.dll. 3.8 /lib: Alternate format essential libraries (optional) See the section on /var/opt for more information. 3.9 /mnt: Mount point for a temporarily mounted filesystem (optional) 3.9.1 Purpose If the root filesystem is TVFS or another filesystem that supports symlinks then this directory may be provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not not affect the manner in which any program is run. No program should rely on this location. 3.10 /opt: Add-on application software packages 3.10.1 Purpose /opt is reserved for the installation of add-on application software packages. (e.g. OpenOffice or other _huge_ software packages that are in no way part of a default Unix installation). A package to be installed in /opt must locate its static files in a separate /opt/ directory tree, where is a name that describes the software package. /opt may be installed onto another filesystem that UNIXROOT. Currently /opt is empty. 3.10.2 Requirements /opt/ Static package objects The directories /opt/bin, /opt/book, /opt/doc, /opt/help, /opt/include, /opt/info, /opt/lib and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories. Programs to be invoked by users must be located in the directory /opt//bin. If the package includes UNIX manual pages, they must be located in /opt//man and the same substructure as /usr/share/man must be used. Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information. No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock. Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator. 3.11 /sbin: System binaries Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. These are basically programs like fdisk which are currently not part of the UnixOS/2 distribution because this functionality is provided by the OS/2 base system. Therefore /sbin is currently empty. 3.12 $TMPDIR: Temporary files 3.12.1 Purpose The TMPDIR directory must be made available for programs that require temporary files. TMPDIR must use forward slashes as directory separator. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. 4. The /usr Hierarchy 4.1 Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. ... Large software packages must not use a direct subdirectory under the /usr hierarchy. 4.2 Requirements The following directories are required in /usr: /usr/bin Most user commands /usr/include Header files included by C programs /usr/lib Libraries /usr/local Local hierarchy (EMPTY after main installation) /usr/sbin Non-vital system binaries /usr/share Architecture-independent data 4.3 Specific Options /usr/X11R6 X Window System, version 11 release 6 /usr/games Games and educational binaries (optional) /usr/lib Alternate Format Libraries (optional) /usr/src Source code (optional) An exception is made for the X Window System because of considerable precedent and widely-accepted practise. 4.4 /usr/X11R6: X Window System, Version 11 Release 6 4.4.1 Purpose This hierarchy is reserved for the X Window System, version 11 release 6, and related files. 4.5 /usr/bin: Most user commands 4.5.1 Purpose This is the primary directory of executable commands on the system. /usr/bin must be in PATH. 4.5.2 Specific Options The following directories must be in /usr/bin, if the corresponding subsystem is installed: /usr/bin/mh Commands for the MH mail handling system (optional) The following files must be in /usr/bin, if the corresponding subsystem is installed: awk bash ksh perl python tclsh wish expect 4.6 /usr/include: Directory for standard include files. 4.6.1 Purpose This is where all of the system's general-use include files for the C programming language should be placed. 4.6.2 Specific Options The following directories must be in /usr/include if the corresponding subsystem is installed: /usr/include/bsd BSD compotibility include files 4.7 /usr/lib: Libraries for programming and packages 4.7.1 Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users of shell scripts. Applications may use a dingle subdirectory under /usr/lib. If an application uses a directory, all architecture-dependent data exclusively used by the application must be placed whithin that subdirectory (for example the perl5 subdirectory for Perl5 modules and libraries). /usr/lib must be in LIBPATH. For every dll .dll there must be provided a static library .a and an import library .lib. 4.8 /usr/lib: Alternate format libraries (optional) 4.8.1 Purpose /usr/lib performs the same role as /usr/lib for an alternate binary format. Local system administrators who do not agree with the UnixOS/2 library police of static .a and import .lib libraries may use /usr/libstatic and /usr/libimport to provide static and import libraries with a different naming scheme. 4.8.2 Specific Options The directory /usr/libstatic may be used by local system administators to provide static libraries with .lib suffix. The directory /usr/libimport may be used by local system administrators to provide import libraries with .a suffix. 4.9 /usr/local: Local hierarchy 4.9.1 Purpose The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. 4.9.2 Requirements The following directories must be in /usr/local: /usr/local/bin Local binaries /usr/local/games Local game binaries /usr/local/include Local C header files /usr/local/lib Local libraries /usr/local/sbin Local system binaries /usr/local/share Local architecture-independent hierarchy /usr/local/src Local source code /usr/local/share provides the same substructure as /usr/share. 4.9.3 Specific Options If directories /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local. 4.10 /usr/sbin: Non-essential standard system binaries 4.10.1 Purpose This directory contains any non-essential binaries used exclusively by the system administrator. System administration programs that are required for system repair, system recovery, or other essential functions must be placed in /sbin instead. 4.11 /usr/share: Architecture-independent data 4.11.1 Purpose The /usr/share hierarchy is for all read-only architecture independent data files. This hierarchy is intended to be shareable among all architecture platforms of a given OS; ... Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. 4.11.2 Requirements The following directoris must be in /usr/share /usr/share/man Online manuals /usr/share/misc Miscellaneous architecture-dependent data 4.11.3 Specific Options The following directories must be in /usr/share if the corresponding subsystem is installed: /usr/share/book OS/2 online documentation /usr/share/dict Word lists /usr/share/doc Miscellaneous documentation /usr/share/games Static data files for /usr/games /usr/share/help OS/2 help files (if there are any; currently empty) /usr/share/info GNU Info system's primary directory /usr/share/locale Locale information /usr/share/nls Message catalugs for Native language support /usr/share/sgml SGML and XML data /usr/share/terminfo Directories for terminfo database /usr/share/tmac troff macros not distributed with groff /usr/share/zoneinfo Timezine information and configuration It is recommended that application-specific, architecture-independent directories be placed here. Such directories include groff, perl, ghostscript, and texmf. 4.11.4 /usr/share/dict: Word lists (optional) ... 4.11.5 /usr/share/man: Manual pages 4.11.5.1 Purpose This section details the organization for manual pages throughout the system, including /usr/share/man. Also refer to /var/cache/man. The primary of the system is /usr/share/man. /usr/share/man contains manual information for commands and data under the / and /usr filesystems. Manual pages are stored in //man/. An explanation of , ,
and is given below. A description of each section follows: - man1: User programs Manual pages that describe publicly accessible commands are contained in this chapter. Most program documentation that a user will need to use is located here. - man2: System calls This section describes all of the system calls (requests for the kernel to perform operations). - man3: Library functions and subroutines Section 3 describes program library routines that are not direct calls to kernel services. This and chapter 2 are only really of interest to programmers. - man4: Special files Section 4 describes the special files, related driver functions, and networking support available in the system. - man5: File formats The formats for many data files are documented in the section 5. This includes various include files, program output files, and system files. - man6: Games This chapter documents games demos, and generally trivial programs. Different people have various notions about how essential this is. - man7: Miscellaneous Manual Pages that are difficult to classify are designated as being section 7. The troff and other text processing macro packages are found here. - man8: System Adminitration Programs used by system administrators for system operation and maintainance are documented here. This includes UnixOS/2 specific programs. Some of these programs are also occasionally useful for normal users. 4.11.5.2 Specific Options The following directories, or symbolic links to directories, must be in /usr/share//, unless they are empty: //man1 User programs (optional) //man2 System calls (optional) //man3 Library calls (optional) //man4 Special files (optional) //man5 File formats (optional) //man6 Games (optional) //man7 Miscellaneous (optional) //man8 System administration (optional) The component
describes the manual section. ... 4.11.6 /usr/share/misc: Miscellaneous architecture-independent data This directory contains miscellaneous architecture-independent files which do not require a separate subdirectory under /usr/share. 4.11.6.1 Specific Options The following files must be in /usr/share/misc, if the corresponding subsystem is installed: ascii ASCII character set table (optional) magic Default list of magic numbers for the file command (optional) termcap Terminal capability database (optional) termcap.db Terminal capability database (optional) Other (application-specific) files may appear here, but a distributor may place them in /usr/lib at their discretion. 4.11.7 /usr/share/sgml: SGML and XML data (optional) ... 4.12 /usr/src: Source code (optional) 4.12.1 Purpose Any non-local source code sould be placed in this subdirectory. 5. The /var Hierarchy 5.1 Purpose /var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files. ... Applications must generally not add directories to the top level of /var. Such directories should only be added of they have some system-wide implication, and in consultation with the FHS mailing list. 5.2 Requirements The following directories are required in /var: /var/cache Application cache data /var/lib Variable state information /var/local Variable data for /usr/local /var/lock Lock files /var/log Log files and directories /var/opt Variables data for /opt /var/run Variables relevant to running processes /var/spool Application spool directory /var/tmp Temporary files preserved between system reboots 5.3 Specific Options The following directories must be in /var, if the corresponding subsystem is installed: /var/games Variable game data (optional) /var/mail User mailbox files (optional) /var/yp Network Information Service (NIS) database files (optinal) 5.4 /var/cache: Application cache data 5.4.1: Purpose /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system. Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of disk space shortage). No other requirements are made on the data format of the cache directories. 5.4.2 Specific Options /var/cache/fonts Locally-generated fonts (optional) /var/cache/man Locally-formatted manual pages (optional) /var/cache/www WWW proxy or cache data (optional) /var/cache/ Package-specific cache data (optional) 5.4.3 /var/cache/fonts: Locally-generated fonts (optional) ... 5.4.4 /var/cache/man: Locally-formatted manual pages (optional) ... 5.5 /var/games: Variable game data (optional) ... 5.6 /var/lib: Variable state information 5.6.1 Purpose This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. User must never need to modify files in /var/lib to configure a package's operation. State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data. An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data. There is one required subdirectory, /var/lib/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution. /var/lib/ is the location that must be used for all distribution packaging support. Different distributions may use different names, of course. 5.6.2 Requirements /var/lib/misc Miscellaneous state data /var/lib/unixos2 UnixOS/2 package support (?) 5.6.3 Specific Options The following directories must be in /var/lib, if the corresponding subsystem is installed: /var/lib/ Editor backup files and state (optional) /var/lib/ Packaging support files (optional) /var/lib/ State data for packages and subsystems (optional) /var/lib/hwclock State directory for hwclock (optional) /var/lib/xdm X display manager variable data (optional) 5.7 /var/lock: Lock files 5.7.1 Purpose Lock files should be stored within the /var/lock directory structure. ... 5.8 /var/log: Log files and directories 5.8.1 Purpose This directory contains miscellaneous log files. Most logs must be written to this directory or an appropriate subdirectory. 5.8.2 Specific Options The following files must be in /var/log, if the corresponding subsystem is installed: lastlog Record of last logon of each user messages system messages from syslogd wtmp record of all logins and logouts 5.9 /var/mail: User mailbox files (optional) ... 5.10 /var/opt: Variable data for /opt ... 5.11 /var/run: Run-time variable data 5.11.1 Purpose This directory contains system information data describing the system since it was booted. Files uder this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. Process identifier (PID) files, which where originally placed in /etc, must be placed in /var/run. The naming convention for PID files is .pid. For example, the crond PID file is named /var/run/crond.pid. 5.11.2 Requirements ... 5.12 /var/spool: Application spool data 5.12.1 Purpose /var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after is has been processed. 5.12.2 Specific Options The following directories must be in /var/spool, if the corresponding subsystem is installed: /var/spool/lpq Printer spool directory (optional) /var/spool/mqueue Outgoing mail queue (optional) /var/spool/news News spool directory (optional) /var/spool/rwho Rwhod files (optional) /var/spool/uucp Spool directory for UUCP (optional) 5.12.3 /var/spool/lpd: Line-printer daemon print queues (optional) ... 5.12.4 /var/spool/rwho: Rwhod files (optional) ... 5.13 /var/tmp: Temporary files preserved between system reboots ... 5.14 /var/yp: Network Information Service (NIS) database files (optional) ... ------------------------------------------------- Shortcut of all that stuff above: 1. The UnixOS/2 base packages (all programs and libraries that are required to finish the installation of a package successfully) belong into the / hierarchy. Their docs belong into the /usr hierarchy. This means: If a program from a package belongs into /bin then the package has to be compiled using the following options: ./configure --prefix=/usr --bindir=/bin --libdir=/lib \ --mandir=/usr/share/man --infodir=/usr/share/info If a library from a package belongs into /lib but none of its programs into /bin then the package has to be compiled using: ./configure --prefix=/usr --libdir=/lib --mandir=/usr/share/man \ --infodir=/usr/share/info 2. The normal UnixOS/2 distribution has to be placed into /usr. This means ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info Another thing: Some packages (like gawk) use prefix/libexec/awk to store some additional executables. After reading the FHS carefully I think these files should go into /prefix/lib/awk, i.e. this would require the additional flag --libexecdir=/usr/lib. 3. After the normal installation /usr/local is empty. The following software has to be placed into /usr/local (not into / and not into /usr): a) Software that is compiled by a user for his own purpose, ie.: If you compile software for yourself don't pollute the /usr tree use /usr/local instead! b) Software that is some kind of Unix software but is currently not part of the UnixOS/2 distro or doesn't comply to the UnixOS/2 standard. (e.g. the normal precompiled packages with their own philosophy you get from hobbes) c) Software that is _huge_ in some sense (don't put Mozilla or OpenOffice here). d) Software that is some kind of Unix software and delivered with the UnixOS/2 distro but not considered as part of the "normal" distro whatever the reason for this may be. 4. Currently /sbin, /usr/sbin and /usr/local are empty. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 2 ==========================** Date: Sat, 14 Sep 2002 10:22:02 +0200 (CEST) From: Mentore Siesto Subject: Re: Final FHS On Sat, 14 Sep 2002, Andreas Buening wrote: AB >Hello! AB > AB >I've just finished the updated filesystem hierarchy for UnixOS/2. AB >The document is not complete in the sense that all sections have been AB >filled with text but I guess I've now included all stuff that is relevant AB >for UnixOS/2 (and also some stuff that is most likely irrelevant). Andreas, when this will be complete, may I translate it in Italian and publish it for the Italian Os/2 - eCS users? -- Mentore Siesto Team Os/2 Italy **= Email 3 ==========================** Date: Sat, 14 Sep 2002 14:26:21 +0200 From: Andreas Buening Subject: Re: Final FHS Mentore Siesto wrote: > > On Sat, 14 Sep 2002, Andreas Buening wrote: > > AB >Hello! > AB > > AB >I've just finished the updated filesystem hierarchy for UnixOS/2. > AB >The document is not complete in the sense that all sections have been > AB >filled with text but I guess I've now included all stuff that is relevant > AB >for UnixOS/2 (and also some stuff that is most likely irrelevant). > > Andreas, > > when this will be complete, may I translate it in Italian and publish it > for the Italian Os/2 - eCS users? Sure. As you can see I've also included the original license conditions. You need the permission of the copyright holders only if you want to translate the license itself. :-) Btw., I guess, this document belongs into /usr/share/man/man8/fhs.8 and the italian version into /usr/share/man/it/man8/fhs.8. :-) bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 4 ==========================** Date: Sat, 14 Sep 2002 14:41:28 +0200 From: Andreas Buening Subject: Re: Final FHS IanM wrote: > > Hi Andreas > > >Ian, if there are no severe objections against this document, could you > >put it on the UnixOS/2 webpage? I'm thinking about something like > > Sure can. Great! > >so that we have a written documentation instead a list of more or less > >archived mails. :-) > > I though I was the only one ;-) Me, too. ;-) Btw. where will be the UnixOS/2 start page? http://unix.os2site.com/sw And, could you also create the source and binary tree on the ftp server we were talking about some time ago so that every maintainer can get write access to "his" directories? I'm going to create the ux2emx library and want to rebuild m4 which will be the first package that is compliant to the UnixOS/2 filesystem structure. :-) (If anybody has a better name for this lib than ux2emx, please tell me! Maybe emxext, unixos2, ux2ext?) [snip] bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 5 ==========================** Date: Sat, 14 Sep 2002 18:38:39 +1000 (EST) From: "IanM" Subject: Re: Final FHS Hi Andreas >Ian, if there are no severe objections against this document, could you >put it on the UnixOS/2 webpage? I'm thinking about something like Sure can. >so that we have a written documentation instead a list of more or less >archived mails. :-) I though I was the only one ;-) Cheers IanM WHOA!!! That was close! You almost caught me caring. **= Email 6 ==========================** Date: Sat, 14 Sep 2002 23:24:04 +1000 (EST) From: "IanM" Subject: FTP access for package maintainers Hi Andreas >Btw. where will be the UnixOS/2 start page? >http://unix.os2site.com/sw Good a place as any, I've also added "root" which will be a mirror of the entire installed tree, very experimental at present and I may also drop that in http://unix.os2site.com/sw both as the directory structure, and a compressed archive with install script(s). At present its on the same drive, just not web visible. >And, could you also create the source and binary tree on the >ftp server we were talking about some time ago so that every >maintainer can get write access to "his" directories? If those maintainers can drop me an email, specifying username/pw, and package directory and I will give them FTP write (and read) access. Once unixos2.com is on a higher speed pipeline I will also enable FTP for the masses. >I'm going to create the ux2emx library and want to rebuild >m4 which will be the first package that is compliant to >the UnixOS/2 filesystem structure. :-) >(If anybody has a better name for this lib than ux2emx, >please tell me! Maybe emxext, unixos2, ux2ext?) I vote for unixos2 (keep it simple) Cheers IanM "I used to be a bartender... at the Betty Ford clinic." s.w.