[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: extension of lsb packages



> 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
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC



Reply to: