What is svgalib-dummy good for?
-------------------------------

This package is meant for all those who installed e.g. ghostscript or
gnuplot and thought "Why the f*k I should also install that svgalib??
I'll never use console graphics, I have X!". Yes, those packages
depend on svgalib (as many others do), because they *can* use it.
Nevertheless, they *need not* use it, they work with X pretty well, too.

Following current Debian policy [1], packages that can be reasonably
build with some option that requires a shared library, should be built
with that option, and the user has to install the appropriate library,
too. This is usually no big deal, but installing svgalib has some
disadvantages:

 - You have to configure it first, otherwise it spits out some error
   messages each time it is initialized (e.g. when you start
   ghostscript). Configuring it isn't trivial, you have to know some
   facts about your graphics hardware.

 - svgalib is somewhat verbose on startup, you get 4 or 5 lines of
   infos you're not interested in.

svgalib-dummy is the solution for all this: It installs dummy versions
of libvga*.so.*, that contain all necessary symbols so that it can be
linked, but the initialization simply fails (without a message :-).

Another important point is: On several architectures (e.g. m68k), a
real svgalib isn't available, since it's not very portable. On those
systems, you couldn't install anything that (directly or indirectly)
depends on svgalib, since it simply didn't exist. That really was a
mess. Also here, svgalib-dummy helps.

The svgalib-dummyg1 package also includes the few headers needed to
compile programs with svgalib. There is no extra -dev package, because
IMHO Debian already has enough packages and I didn't want to add one
more just for 2 header files... Anyway, you should be able to compile
programs that need svgalib with only svgalib-dummyg1 installed. But
only dynamic linking is supported, static dummy libraries wouldn't
make much sense :-) (Another reason why the -dev package would be too
small to be reasonable.)


If you're maintainer of a package that links with svgalib
---------------------------------------------------------

There are several issues to be considered if you maintain a package
that links with svgalib. Note that the following isn't policy or
anything like that, it is some kind of consensus reached on
debian-devel and in private discussions about svgalib-dummy support.

There are two kinds of programs that use svgalib: those that rely only
on svgalib for output, and those that in addition have other display
methods (e.g. X11). The first class (svgalib-only programs) are
useless with svgalib-dummy, they need the real lib. In their
dependencies, they should mention only svgalibg1, not svgalib-dummyg1.

Programs of the second class can also work if svgalib-dummy is
installed in place of the real lib. Therefore their dependencies
should read something like

  Depends: ..., svgalibg1 | svgalib-dummyg1, ...

The shlibs files of all svgalib* packages contains as dependency just
'svgalibg1', which is correct for packages of the first class
(svgalib-only). This was done because this is the majority of
svgalib-using packages [2]. This means: If your package is
svgalib-only, you have to do nothing special... But note that, since
svgalib is Architecture: i386 alpha, your package should have that
architecture statement, too (instead of Architecture: any). The real
svgalib is available only on i386 and alpha, and your package depends
on it, so it doesn't make any sense to build it for other
architectures.

But if your package can function equally with the real or the dummy
lib, you have to modify dependencies a bit. To do this, insert the
following code in debian/rules between the calls of dpkg-shlibdeps and
dpkg-gencontrol:

	set -e; \
	if ! grep svgalib-dummyg1 debian/substvars >/dev/null ; then \
		mv debian/substvars debian/substvars-unhacked ; \
		sed -e 's/svgalibg1\( *([^)]*)\)\{0,1\}/& | svgalib-dummyg1\1/' <debian/substvars-unhacked >debian/substvars; \
		rm debian/substvars-unhacked; \
	fi

This replaces the svgalibg1 dependency by an alternative with
svgalib-dummyg1, and versioned dependencies are preserved.

Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>, 17 Feb 1998

---

 [1] Quoting the Debian policy manual 2.1.2.2:

  	4.2 Packages which can use the X shared libraries
  	
  	   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.      
  			  
  	   Such programs should be configured with X support, and should declare 
  	   a dependency on xlib6 (for the X11R6 libraries). Users who wish to use
  	   the program can install just the relatively small xlib package, and do
  	   not need to install the whole of X.
  			  
  	   Do not create two versions (one with X support and one without) of
  	   your package.                                           

 Common sense is that this applies to analogous cases like svgalib, too.

 [2] Until version 1:1.2.13-1 of svgalib and 1:1.2.11-1 of
svgalib-dummy, the shlibs files of both packages contained the
alternative, i.e.

  libvga 1 svgalibg1 | svgalib-dummyg1

But it showed that this was the wrong thing to do. It pretends that
any svgalib-based program would work with svgalib-dummy, but this is
not the case if there's no alternative display method. If your package
has been compiled with one of the two versions above (or even older),
you should recompile it.

