[csw-maintainers] packages names normalization (long)

[Dagobert Michelsen]

Hi Peter,

Am 29.04.2009 um 17:26 schrieb Peter FELECAN:
> Reading the standards page,
> http://www.opencsw.org/standards/pkgcreation, I understand that the
> standard for naming CSW splitted packages is:
>
> PKGname	     shortname
> ------------ ---------
> CSWsoftrt    soft_rt
> CSWsoftdevel soft_devel
> CSWsoftdoc   soft_doc
>
> Some of the cited rationales are: to optimize the download size of the
> required packages, to offer a better granularity in packages
> inter-dependencies, &c.
>
> For the moment, this standard is not applied consistently, but I
> understand that it is now enforced.
>
> Here is a more developed functional relation with the suffixes cited  
> above:
>
> _rt    : run-time
>
>         Any component needed to run the product or *derived* products:
>         shared libraries, &c
>
> _devel : development
>
>         Any component needed for developing *derived*  but not
>         needed for running it: headers, static libraries, pkgconfig
>         elements, &c
>
> _doc   : documentation
>
>         Any component documenting the product and/or the creation of
>         *derived* products.
>
> There is something missing: the nil suffix which, in my opinion,
> group the components which are *run*, i.e. binaries, shell scripts, &c

It may also very well be a meta-package to say "I just want to
use this software". In most cases this will be the binaries and
depend on _rt. However, in packages whose sole purpose is the
development of software things get more complicated as I'll
illustrate below.

> A package with a nil suffix, using the above examples, has the form:
>
> CSWsoft      soft
> CSWsoftrt    soft_rt
> CSWsoftdevel soft_devel
> CSW softdoc  soft_doc
>
> Why do I think that we should have nil suffixed packages names:
>
> 1. Installing the product by:
>
>   pkg-get install softrt

_rt-packages will usually be never installed manually, they are
meant to be pulled in as dependencies. Factoring out _rt to
minimize impact of dependencies is one of the reasons that
runtime-stuff is actually split off in a separate package.

>
>
>   is less intuitive than:
>
>   pkg-get install soft
>
> 2. Installing the product's binaries is not always necessary to run
>   *derived* products, its run-time is however necessary.

True.

> Giving a full example is probably a good way to enhance the
> documentation of this standard. Consequently, here is the splitting of
> the autogen project:

Bad example IMHO, as the sole purpose of autogen is to aid
in software development and needed for compilation. No user
will use it.

> CSWautogen      autogen
> CSWautogenrt    autogen_rt
> CSWautogendevel autogen_devel
> CSWautogendoc   autogen_doc
>
> and their respective content is (I omitted the /opt/csw prefix):
>
> autogen:
>
> 	bin/autogen
> 	bin/autoopts-config

By default bin/*-config is put in _devel in GAR.

>
> 	bin/columns
> 	bin/getdefs
> 	bin/xml2ag
> 	share/autogen/aginfo.tpl
> 	share/autogen/aginfo3.tpl
> 	share/autogen/agman-lib.tpl
> 	share/autogen/agman1.tpl
> 	share/autogen/agman3.tpl
> 	share/autogen/autoopts.m4
> 	share/autogen/confmacs.tpl
> 	share/autogen/conftest.tpl
> 	share/autogen/fsm-macro.tpl
> 	share/autogen/fsm-trans.tpl
> 	share/autogen/fsm.tpl
> 	share/autogen/getopt.tpl
> 	share/autogen/optcode.tpl
> 	share/autogen/opthead.tpl
> 	share/autogen/options.tpl
> 	share/autogen/optlib.tpl
> 	share/autogen/optmain.tpl
> 	share/autogen/rc-sample.tpl
> 	share/autogen/stdoptions.def
> 	share/autogen/usage.tpl
> 	share/man/man1/autogen.1
> 	share/man/man1/autoopts-config.1

Same is for the manpage.

>
> 	share/man/man1/columns.1
> 	share/man/man1/getdefs.1
> 	share/man/man1/xml2ag.1
>
> autogen_rt:
>
> 	lib/libguileopts.so.0.0.1
> 	lib/libopts.so.25.7.0
>
> 	share/doc/autogen/AUTHORS
> 	share/doc/autogen/COPYING
> 	share/doc/autogen/ChangeLog
> 	share/doc/autogen/INSTALL
> 	share/doc/autogen/NEWS
> 	share/doc/autogen/README
> 	share/doc/autogen/THANKS
> 	share/doc/autogen/TODO

Docs usually go into the base package if there is no _doc.

> autogen_devel:
>
> 	include/autoopts/options.h
> 	include/autoopts/usage-txt.h
> 	lib/libguileopts.a
> 	lib/libopts.a
> 	lib/pkgconfig
> 	lib/pkgconfig/autoopts.pc
> 	share/aclocal/autoopts.m4
> 	share/aclocal/liboptschk.m4
> 	share/man/man3/ao_string_tokenize.3
> 	share/man/man3/configFileLoad.3
> 	share/man/man3/optionFileLoad.3
> 	share/man/man3/optionFindNextValue.3
> 	share/man/man3/optionFindValue.3
> 	share/man/man3/optionFree.3
> 	share/man/man3/optionGetValue.3
> 	share/man/man3/optionLoadLine.3
> 	share/man/man3/optionNextValue.3
> 	share/man/man3/optionOnlyUsage.3
> 	share/man/man3/optionProcess.3
> 	share/man/man3/optionRestore.3
> 	share/man/man3/optionSaveFile.3
> 	share/man/man3/optionSaveState.3
> 	share/man/man3/optionUnloadNested.3
> 	share/man/man3/optionVersion.3
> 	share/man/man3/strequate.3
> 	share/man/man3/streqvcmp.3
> 	share/man/man3/streqvmap.3
> 	share/man/man3/strneqvcmp.3
> 	share/man/man3/strtransform.3
>
> autogen_doc:
>
> 	share/doc/autogen/autogen.dvi
> 	share/doc/autogen/autogen.pdf
> 	share/doc/autogen/autogen.ps
> 	share/info/autogen.info
> 	share/info/autogen.info-1
> 	share/info/autogen.info-2

texinfo pages are put in the main-package as they can be
thought of another form of manpages.

> All your comments are welcome and when we agree it should be nice to
> update the standards page.

Additionally, there should be license files
   /opt/csw/share/doc/autogen/license
   /opt/csw/share/doc/autogen_rt/license
   /opt/csw/share/doc/autogen_devel/license
   /opt/csw/share/doc/autogen_doc/license
with the contents of share/doc/autogen/COPYING


Best regards

   -- Dago