[csw-maintainers] discussion: stub package naming

Philip Brown phil at bolthole.com
Tue May 17 18:37:48 CEST 2011


(I had suggested that Ben start a vote on this, but since he hasnt,
and stuff is piling up, I'll start this additional discussion thread)

There is currently a disagreement about how "stub" packages should
have their catalog name set.

Reminder: Stub packages, are created for purposes of renaming older
packages, that have non-desired names.
They are empty packages, that allow an automated {pkg-get, pkgutil}
update, to pull in the "correct", newer packages.

Almost by definition, the older packages will have non-standard naming.
The question is what to do about the stub package naming.

the SVR4 PKG name must be the same as the old one, there is no choice there.

Here is where the difference of opinion lies: the "catalog" name.

As release manager,  I think that the most consistent thing to do, is
have the catalog name, exactly match the original name, but with
"_stub"
added.
Thus  "libfoo_devel", becomes "libfoo_devel_stub"
I say "consistent", because the stub package, is supposed to be a
placeholder for [old package], so as such, it should conform to [old
package] as tightly as possible.
It also makes searches for it easier. If someone is remembering the
existance of "libfoo_devel", they are going to search directly for
that. In that case, libfoo_devel_stub" is more likely to show up in
the search.
It has been mentioned that pkgutil's "fuzzy search" can in many cases
still show the stub. But there are more ways to search than just that.

Other people are tending to say that the stub catalog name should
follow our *new* standards.
ie: if original is  CSWlibfoodev, libfoo_devel
stub is   CSWlibfoodev, libfoodev_stub

This seems to stem basically from the fact that this is the current
default gar behaviour, and they dont want to spend time updating gar
code to do it the other way, rather than any argument that they
specifically want the naming done that way.

Other people's opinions on this matter are hereby requested.


More information about the maintainers mailing list