Alan wrote:
> 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.
>
The upgrade across packaging systems is going to be very interesting,
but for now we'll limit the scope to installing new versions of Indiana.
> 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.)
>
One simple way to handle this is for each package to deliver
it's own fonts.dir file containing the fontname -> file mappings
belonging to it. These files would be delivered to a well known
directory under each font dir, and the name of the file would
be the name of the package delivering it. A simple transient SMF service
should then be created, which would combine the fonts.dir files when
needed. A refresh action (see bug 578) could be set up to watch for
deliveries of files into the well known directories as part of the
Xserver install; subsequent deliveries of new fonts would automatically
cause rebuilding of the necessary fonts.dir files.
> - 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.
>
I'd do this the same way; rather than merging at pkg install time,
keep the component pieces and merge as needed when new files are
delivered. All that really happens is that the postinstall scripts
stop being apparently part of the packaging infrastructure, and
become part of the normal operating behavior of the component.
Note that the refresh service does nothing when packages are installed
on a non-live image; the idea is that when the image is booted the
transient service will perform the required actions.
> 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 at 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.
>
We can nuke all this as long as we make sure that the smf service will
do the right thing at startup.
>
> 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.
IPS can handle directories changing to symbolic links... but the
directory needs to be in a older pkg version. In other words, if
version 1.1 of a package has /usr/include/GL as a directory, and
version 1.2 has it as a link, this works fine - as long there are
no other packages in the new package set that left files under
/usr/include/GL, since then that directory won't be deleted
and the symlink creation will fail.
>
>
> 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.
yup
>
> 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.
hmm.... we would move this into a one time cleanup, I think; we've not
given the problem of upgrading from old versions much thought yet.
>
> 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.
This will work completely differently.
- Bart
