RFC: New naming scheme for GNUstep packages

[Yavor Doganov]

For the GNUstep packaging policy I'm writing [1] I am considering a
new naming scheme, supposed to resolve (well, mostly) ftpmasters'
desire to avoid periods in the package names.  I think it would be
also more natural for users, as there won't be confusing things like
`camaelon.app' (which is not an app at all, but a bundle).

Here is a simple table that illustrates it:

+------+-------------+-------------+------------------+------------------+
|Type  |Current      |Current      |New Source name   |New Binary names  |
|      |Source       |Binary       |                  |                  |
|      |package name |package names|                  |                  |
|      |             |             |                  |                  |
+------+-------------+-------------+------------------+------------------+
|App   |foo.app foo  |foo.app      |foo.app [3]       |foo.app           |
|      |[2]          |             |                  |                  |
+------+-------------+-------------+------------------+------------------+
|Frame-|foo.framework|libfooN      |foo [4]           |libfooN libfoo-dev|
|work  |             |libfoo-dev   |                  |[5]               |
|      |             |foo.framework|                  |                  |
+------+-------------+-------------+------------------+------------------+
|Bundle|foo.app      |foo.app      |gnustep-foo-bundle|gnustep-foo-bundle|
+------+-------------+-------------+------------------+------------------+
|Tool  |foo.tool     |foo.tool     |gnustep-foo-tool  |gnustep-foo-tool  |
+------+-------------+-------------+------------------+------------------+

Bundles that are specific for Etoile (which is *not* the case of
Camaelon, even if it's part of Etoile) -- i.e. those which depend on
Etoile libraries and/or are only useful in the Etoile desktop could be
named etoile-foo-bundle.  GNUstep Back (although packaged as bundles)
will have an exception.

WDYT?  (Especially interested in ftpmasters' opinion/comments, as this
thing depends on their approval.)

[1] Still in the works, no ETA :-(  But the renaming of the packages
    does not depend on its existence.
[2] There is a discrepancy for some of the .app packages mostly
    because tla-buildpackage didn't handle periods in package names.
    Hubert fixed this limitation recently by transforming the period
    to a dash (to comply with Arch's arcane conventions).
[3] These are the most common packages, and gnustep-foo-app seems
    rather unnatural given the fact Foo.app is the usual name in the
    GNUstep world.  We *may* attempt to rename them too in the future
    if GNUstep is not the only offender of the
    no-period-in-package-names rule.
[4] Typically they are named FooKit (with notable exceptions like
    Renaissance), so collisions ought to be rare.  My opinion is that
    there's no point to append .framework to GNUstep libraries,
    although for extra safety we may continue to do so.
[5] We'll annihilate all foo.framework binary packages, which are
    dummy empty packages depending on the -dev.  The assumption was
    that interested Debian users who are GNUstep developers would find
    them easier, but my humble opinion is that this assumption is
    mistaken.  Any developer who uses Debian as a platform already
    knows the naming scheme Debian uses for libraries.
    GNUstep/Objective-C libraries should be no different.

    (Some clarification: GNUstep has separate concepts for "library"
    and "framework".  A library is a shared library in the same way we
    all recognize it.  A framework is a shared library with Resources,
    i.e. architecure-independent data.  Mac OS X go further (TTBOMK,
    never used that system) in bundling a "framework" to contain
    several related libraries and their version of GCC has the
    -framework option to link against the whole bundled mess.  This
    does not concern Debian; at least I cannot think of a reason why
    it should.  For our purpose, GNUstep libraries and frameworks are
    treated equally.)