> long time. Distribution vendors have never suggested something > better. If you have a better solution, do please suggest it.
The md5 sum of the header+payload, a value present in all .rpm's I've ever seen and/or used, as a "pkgid" creates a unique name space for lsb c/c/c/ packages without the necessity of a "lsb-" prefix in the package name. Collisions (if any) can be avoided by using, say, package size, also present in all legacy .rpm's, as a tie breaker. The scheme generalizes to other formats, like tar/cpio balls and .deb's, trivially. Prefix the md5sum with a version/type, include an explicit octet length, and a "pkgid" can even be extended to include the current "lsb-" and ".lsb" package names if you so desire. What's important to note is that "pkgid's" will collide, not package names, and hence demanding a clean package name space a priori is not necessary. The scheme also permits legacy packaging to become lsb c/c/c w/o the necessity of a rebuild that does no more than s/^/lsb-/. The goal should be to associate an attribute (i.e. lsb c/c/c) with an object identifier in order to provide an authoritative reference database for the name space. Much of the management of the authoritative reference database could/should be delegated back to distro vendors, leading to a hierarchical access (i.e. lsb -> pkgid -> vendordb -> packagename) that has the vendor implicitly on the access, rather than explicitly in the package name itself. There is, of course, nothing preventing any vendor from honking their wares in the package name itself, but does get lsb out of the business of "standardizing" package names/suffixes a priori in order to create an authoritative LANANA name space. 73 de Jeff -- Jeff Johnson ARS N3NPQ [EMAIL PROTECTED] ([EMAIL PROTECTED]) Chapel Hill, NC
