Re: [MiNT] Where should a user put GEM apps

[Paul Wratt <paul.wratt@gmail.com>]

OK, I accidently found the definitive answer on this:
http://sparemint.org/sparemint/FAQ.MiNT -> 5.4 GEM Applications

""
Q: What about GEM stuff and rpm?

A: No problem, go ahead!  However you should also adhere to a certain
   directory structure that is adapted from the FHS rules for
   X Windows System (an AES clone for MiNT clones).

   Please install libraries and headers in

   	/usr/GEM/lib
   	/usr/GEM/include

   GEM libraries are often not very strict about namings and
   this will avoid conflicts.  Furthermore it makes it easier
   to keep an overview of your development stuff.

   No, by default GEM applications should not be installed in

   	/usr/GEM/bin or
   	/usr/GEM/sbin
   	
   except for programs that can run stand-alone, i. e. that don't
   need any non-program files for proper operation in the same
   directory.  Most GEM apps at least need a .rsc file and that
   would fill up that directory with junk (and prevents a
   comfortable uninstallation without the help of rpm).  Create
   a subdirectory under `/opt' instead.  For example the popular
   editor QED by Christian Felsch should go into /opt/qed.

   We don't consider it useful to further subdivide that directory
   into `/opt/editors', `/opt/telecomm', `/opt/midi' and so
   on.  Most desktops have much better means to group software.

   Please don't expect the directory `/usr/multitos' any longer
   (neither `/usr/mint').  This is now `/boot/mint' and `/boot'
   should be a symbolic link to the boot partition (i. e. the
   program `/boot/auto/mint.prg' resp. `/boot/auto/mintnp.prg'
   is the kernel).

   One specialty are help files in ST-Guide format.  ST-Guide
   is a very helpful desk accessory commonly used by GEM
   applications written by Holger Weets.  Unfortunately it is
   non-free software but Sparemint supports it nevertheless.
   If you want to automatically install help files in ST-Guide
   format you should install them in `/usr/GEM/stguide' and
   you can also expect the tools `hcp.ttp', `stool.tos' etc.
   to reside there (in fact the user may make `/usr/GEM/stguide'
   a symbolic link to the actual location; we haven't chosen
   the most common location `/boot/st-guide' resp. `/boot/help'
   because we want to avoid forcing people to install large
   sets of files on the boot drive).  However, you should
   treat failures on the use of hcp or stool as non-fatal
   errors.  Example:

	%post
	/usr/GEM/stguide/hcp.ttp $RPM_BUILD_DIR/%{name}-%{version} \
	    myapp.stg && \
	  /usr/GEM/stguide/stool.tos >/dev/null 2>&1 || :
	
	%postun
	rm -f /usr/GEM/stguide/myapp.hyp /usr/GEM/stguide/myapp.ref
	/usr/GEM/stguide/stool.tos >/dev/null 2>&1 || :
	
   Nonetheless: If you have the choice, use more versatile
   formats than ST-Guide for your help files.  SGML and
   derivates are probably the future, GNU Texinfo can also be
   converted into lots of other formats (including ST-Guide).

   Generally speaking, questions concerning handling of GEM
   specific stuff has not yet been positively decided.  Feel
   free to make own suggestions or improvements to the rules
   outlined here.

5.5 Device Drivers And File Systems

Q: How is such stuff treated?

A: A preliminary approach looks like this:

   1) Drivers should only be installed in

   	/usr/lib/mint/drivers

      This directory is kind of a depot for device drivers and
      file systems (and network interfaces).

   2) Always add a line

   	Requires: mint-util

      to spec files that build or install drivers.  Read the manpage
      drivers(8) and add post-install and post-uninstall sections
      to your spec file:

      	%post
      	/sbin/drivers --install mydev && /sbin/drivers --update
      	
      	%postun
      	/sbin/drivers --uninstall mydev

   3) Be careful with /sbin/drivers, do not install too many drivers.
      For example the package `mintnet' comes with the socket device
      driver `sockdev.xdd' and a whole lot of other drivers and
      network interfaces.  But there is no way for the packager to
      decide which drivers and interfaces are really useful for
      the end-user.  If she installs MiNTNet she will definitely
      want to install or update `sockdev.xdd', so this driver can
      be safely installed.  But for the rest, who knows?

      You can always do `/sbin/drivers --update' in the %post
      section, that will cause drivers that /are/ already activated
      to get updated (i. e. new drivers in /usr/lib/mint/drivers
      will overwrite old ones of the same name in /boot/mint).

      NOTE: The /sbin/drivers program will have trouble if the
      name of the driver does not fit into the 8+3 restriction
      of old file systems (and /boot will reside on such a
      file system).  Please avoid using names that break this
      limit!
""