extension of lsb packages
jbj at redhat.com
Wed Mar 6 06:41:22 PST 2002
> 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
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
be delegated back to distro vendors, leading to a hierarchical access
(i.e. lsb -> pkgid -> vendordb -> packagename) that has the vendor
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
package names/suffixes a priori in order to create an authoritative
73 de Jeff
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
More information about the lsb-discuss