package naming, install directories for 2.0

This has remained unresolved for long enough, let's see if we
can close on it.  We've had a desire to set up our packaging
to meet several criteria:

- follow our own rules for package naming and install locations
- be able to have packages for multiple architectures installed
  at the same time
- be able to have packages for multiple LSB versions installed
  at the same time.

All of these qualified by "when it makes sense" - for example,
some of our packages are not LSB conforming today, and some
probably never will be, and so perhaps it's not strictly
necessary to treat them as if they were.


Right now, we produce the following packages, not including 
the runtime tests suites:

Application tests:
lsbappchk
(unreleased) pkgchk
(unreleased) dynamic checker

Platform tests:
lsblibchk
(unreleased) cmdchk

Build packages:
lsbdev-base
lsbdev-cc
lsbdev-c++
lsbdev-chroot

Sample Implementation:
(tarballs): lsbsi, lsbsi-boot, lsbsi-test, lsbsi-uml
(package): lsb-umlsi

Application Battery:
lsb-apache, lsb-celestia, lsb-tcl, lsb-expect,
lsb-groff, lsb-lynx, lsb-python, lsb-rsync,
lsb-samba, lsb-xpaint, lsb-xpdf
(unreleased) lsb-build-libbat, lsb-openjade


An initial pass was made for "LSB 1.9" to rename some of 
these in a more LSB-conforming manner, so for now we have:
lsb-appchk, lsb-pkgchk, lsb-libchk, lsb-cmdchk
lsb-build-base, lsb-build-cc, lsb-build-c++, lsb-build-chroot
All of these now install to /opt/lsb, as does
lsb-build-libbat which is really a build tool
although it is constructed out of the application battery.

But this renaming didn't really help meet the objective
stated about, because:

1.lsb-xxx is not valid as a package name, unless we
  register xxx with LANANA.  We could use our registered
  provider name, but then we have to call the packages
  lsb-lsb-xxx
2.we hatched a plan to install to a path
  /opt/lsb/<lsbversion>/<arch> to handle the concurrent
  version/architecture issue, but this is not implemented yet
3.even if (2) were in place, the package names also need
  to encode version/arch in such a way that they don't
  conflict with one another.  E.g. if lsb-build-base for
  ia32/LSB 2.0 is installed, we can't install another package
  with the same name for a different architecture or version.
4. appbat programs (which DO strive to be LSB conforming in
  all cases) are named lsb-<app> and install to
   /opt/lsb-<app> as if they were packaged LSB conforming
  by the project rather than as a test program by the LSB.



My take is that this is getting too complicated and
we should give up on trying to solve so many different
problems at once.  So this is a possible proposal:

I. programs that developers/endusers might use should
   go into /opt/lsb; test suites to /opt/lsb/test; 
   application battery programs can go into /opt/lsb/appbat
   (or, alternatively, /opt/lsb/test), and the sample
   implementation to /opt/lsb/si
II. scrap the /opt/lsb/<lsbversion>/<arch> idea and whatever
   matching stuff would have to go into the package name as
   adding too much complexity for the "normal case" in favor
   a few special users (mainly, the LSB team)
III. reserve our "user" package names with LANANA to avoid
    any further renaming hassles
IV. Reserve "test" as a dummy provider name with LANANA,
    allowing lsb-test-xxx to be under our control, and
    use for test suites as well as appbat.

However, I'm not prepared to just make that as a
decision, and in particular I'm not wedded to item II.,
so consider the discussion (re) opened...

In considering this situaton I also decided to file
bugzilla #147 to clarify the naming rules.


=== these are the naming rules from the specification ===


FHS:

/opt : Add-on application software packages

/opt is reserved for the installation of add-on application software
packages.

A package to be installed in /opt must locate its static files in a
separate /
opt/<package> or /opt/<provider> directory tree, where <package> is a
name that
describes the software package and <provider> is the provider's LANANA
registered name


LSB:

Package Naming

Because there is no consistent packaging naming among the various Linux 
distributions, it is necessary for LSB-conformant packages to adhere the

following naming rules to avoid conflicts with packages provided by the 
distributions.

* All LSB package names shall begin with the prefix "lsb-" to avoid 
conflicting with existing packages used by Linux distributions.
    
* If the package name contains only one hyphen (including the one in 
the "lsb-" prefix) then the package name shall be assigned by the 
Linux Assigned Names and Numbers Authority (LANANA), which shall 
maintain a registry of LSB names.

* If the package name contains more than one hyphen (i.e., 
"lsb-www.redhat.com-redhat-database", "lsb-gnome-gnumeric"), then the 
portion of the package name between first and second hyphens shall 
either be an LSB provider name assigned by the LANANA, or it may be 
one of the owners' fully-qualified domain name in lower case (e.g., 
"debian.org", "staroffice.sun.com"). The LSB provider name assigned 
by LANANA shall only consist of the ASCII characters [a-z0-9].