[csw-maintainers] Packaging gems and package naming conventions

Peter FELECAN pfelecan at opencsw.org
Tue Oct 19 14:32:46 CEST 2010

"Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes:

> No dia 18 de Outubro de 2010 17:38, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> escreveu:
>> No dia 2 de Agosto de 2010 09:04, Dagobert Michelsen <dam at opencsw.org> escreveu:
>>> Other topic: documentation. Having both rdoc and ri docs is quite
>>> large, most of the time the documentation is much larger in size
>>> and much, much larger in terms of files. I tend to split it off,
>>> but the standard _doc and -doc suffixes together with the gem
>>> prefix would leave only very little space for the actual gem
>>> name making identification difficult. I tend to increase the
>>> maximum length of package and catalog names for the sake of
>>> consistency.
>> On the package name length topic, opk recently came across
>> libpyglib-2.0-python.so.0, which yields CSWlibpyglib-2-0-python0, a 24
>> characters long pkgname.
> opk made this nice histogram of soname lengths, with cumulative
> percentages.  You can read it as, e.g. 20.1% of sonames are 12
> characters or less.
> The relation between soname lengths and package name lengths is that
> libfoo.so.1 (11 chars) becomes CSWlibfoo1 (10 chars), so on average we
> can expect package names be one character shorter than sonames.  The
> exception is when the sonames are of the form libfoo1.so, and in this
> case the pkgname length is the same.  Catalognames are 3 characters
> shorter, as they don't have the CSW bit.
> [...]
> Looking at the histogram, 97.9% sonames are 31 characters and less, so
> we can fit 98.3% of them into pkgnames with up to 30 characters.  The
> current cutoff point is at 84.6%, which I think is too low, leaving
> 15.4% sonames out.  We could use curtations, but I'd prefer if we
> didn't.  If we nevertheless did, I'd like us to have an algorithmic
> way of shortening package names.
> Thoughts?

>From my point of view, the issue with this statistics is that they take
into account what already exist and not what is needed in the future. If
you work on Debian packages names you'll obtain quite different results.

Let the package names be as long as the underlying packaging system

More information about the maintainers mailing list