[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-i18n-discuss
Subject:    [i18n-discuss] [Fwd: scripts in the current X/font SVR4 packages &
From:       Alan Coopersmith <Alan.Coopersmith () Sun ! COM>
Date:       2008-02-23 2:07:17
Message-ID: 47BF7FD5.2070108 () sun ! com
[Download RAW message or body]

Oops - meant to cc i18n-discuss@opensolaris on this, but typo'ed the
address.

	-alan-

-------- Original Message --------
Subject: scripts in the current X/font SVR4 packages & migrating to IPS
Date: Fri, 22 Feb 2008 18:00:32 -0800
From: Alan Coopersmith <Alan.Coopersmith@Sun.COM>
To: pkg-discuss@opensolaris.org
CC: OpenSolaris X Window System List <xwin-discuss@opensolaris.org>

I've gone through our SVR4 packages to see what class action
& pkg pre/post scripts we currently have and which we'd need
replacement IPS actions for - the full list is at the end of
this message

If we can assume IPS upgrade won't require the hackery we've
got for things the current Solaris upgrade system can't handle,
and we won't be upgrading from Solaris 8 or S10beta to Indiana,
then we're pretty much down to the font metadata files.

For background, we currently support 2 font systems, each of
which has it's own metadata files that are needed to access
the fonts.

1) Traditional X font system (aka X server side fonts):

   - Every directory containing fonts has a fonts.dir file
     which is a text file generated by mkfontdir that maps
     the font names to which files contain the fonts.  Since
     multiple packages deliver fonts to the same directory,
     each package containing fonts delivers an entry for
     fonts.dir and a class action script to update it.
     (If it wasn't for IPS, I'd be working to put a common
      script for this in /usr/sadm/install/scripts/ so that
      we wouldn't keep updating every copy for all the updates
      needed for LU/zones/etc.)

   - Every directory containing TrueType or Postscript fonts
     has a fonts.scale file which has the mappings for files
     in those formats which mkfontdir copies into fonts.dir.
     This is needed currently because the current mkfontdir
     doesn't know how to parse those formats - but we're about
     to deliver a version that does.

     Right now, all deliveries to the same directory containing
     these fonts are from the same package, so we ship a single
     static file in that package, but for Indiana, the g11n teams
     have asked to start delivering fonts from their packages
     into the same directory as the base fonts instead of
     locale-specific directories, so we'd either need to merge
     the text files, or run mkfontscale after a font is added
     to generate them.

   - Directories with fonts may also have fonts.alias files, which
     provide alternate names for fonts - these are text files which
     are currently merged at package install time using a tool called
     installalias which copies over the entries for fonts which are
     installed from template files installed by each package.

You can see examples of these files in directories such as:
	/usr/X11/lib/X11/fonts/TrueType/

2) fontconfig (used by GNOME/KDE/etc. via libXft & libfontconfig)

    - Caches information about fonts in fonts.cache-1 files.

      Currently these are stored in the font directories, but are
      moving to /var/cache/fontconfig shortly (LSARC 2008/140, filed
      a few minutes ago).   They're built by the fc-cache command,
      which we run via the SMF transient service fc-cache at each
      boot.   Normally, fc-cache just compares the directory
      modified time to the cache modified time and updates if the
      directory is newer, but you can force a rebuild if you know
      the cache is out of date.

I've talked about this a little with Bart already - for the fontconfig
caches, the simplest thing would be for IPS, after finishing any
install that installed a font file (*.pcf, *.pcf.{Z,gz,bz}, *.ttf,
*.pfa, etc) to make sure the fc-cache service kicks off another run.

For the older font system, we could do something postrun-like, adding
the mkfontdir, mkfontscale & installalias commands to the list of
commands that need to be run.   Another option would be to try to
emulate the fc-cache model, providing an SMF service that looked in
all the known font directories, and ran the appropriate commands if
the timestamps didn't match, but that will take some work to create.

	-Alan Coopersmith-           alan.coopersmith@sun.com
	 Sun Microsystems, Inc. - X Window System Engineering


Packaging scripts in X today:

Class action scripts in our font packages:

	i.fontsdir - runs mkfontdir to scan the fonts in the directory
	and create fonts.dir listing them.

	r.fontsdir - remove fonts.dir, expecting postremove to recreate it

	i.fontsalias - runs installalias against a list of aliases provided
	with the package, which merges in the ones for fonts that are
	installed into the fonts.alias in each font directory.

	r.fontsalias - remove the file containing the list of aliases for
	this package

	i.ttmapsdir / i.encodingsdir - inserts entries in the ttmaps.dir
	& encodings.dir for encodings/mappings installed by the package.
	r.ttmapsdir / r.encodingsdir - removes the entries
	(I'm not sure if we need this once we're off Xsun altogether.
 	 The Xorg equivalent is static, since we put all the encodings in
	 the base package.)

       	postremove - goes back and regenerates fonts.dir & fonts.aliases
	so they no longer list the fonts removed by this package.


SUNWxorg-mesa/preremove:

This script simply does "rm -rf $BASEDIR/include/GL" with the comment:
	# If the NVIDIA web installation has been run prior to
	# the integration of the OpenGL switcher, it will have
	# created the directory /usr/include/GL which the package
	# programs will refuse to replace with a symlink.
If IPS will handle this without a packaging script, that would be better.


SUNWxwplr/preinstall:
	Deletes the SMF manifest autogenerated by inetconv for xfs on
	systems installed before the xfs manifest was integrated.
	Since that was only S10 beta releases, this can probably just
	go away now.

SUNWxwdem/postinstall:
	removes $BASEDIR/openwin/lib/openwin-menu-demo, an ancient relic
	of the OpenWindows desktop that was created in postinstall scripts,
	but never registered with installf, so it doesn't get removed
	automatically on pkgrm/upgrade.   Shouldn't be needed if we're
	not supporting upgrade directly from Solaris 8 or older.

SUNWxwfnt/postinstall:
	removef's a bunch of files that moved to SUNWxwfsw since pkgrm'ing
	SUNWxwfnt during upgrade broke zones upgrade from S10 (see 6569792)
	 - I really hope IPS can handle this automatically.

-- 
	-Alan Coopersmith-           alan.coopersmith@sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

_______________________________________________
i18n-discuss mailing list
i18n-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/i18n-discuss
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic