Chris Lawrence wrote: > > Well, perhaps the solution is, as joeyh suggested, to munge the magic > in such a way that the package looks like an RPM to RPM (so systems > that use RPM as the package manager don't need to provide a separate > lsb-rpm, just the lsb package infrastructure), but can be > distinguished from a "normal" RPM by tools that need to care about the > difference (like alien) without parsing the package dependencies.
Is the primary reason for wanting a ".lsb" suffix is for RPM v3 coexistence with RPM v4? If so, then Caldera has a patch. http://www.geocrawler.com/archives/3/7337/2001/11/0/7031928/ The LSB specified RPM v3 file format is not unique; therefore, I don't understand the reason for the .lsb file suffix. If the LSB had specified gziped tar files instead, then would we have all LSB formatted .tgz or .tar.gz files to be .lsb named? :-) Let me backup and correct myself. The LSB specifies an "lsb-" prefix for the package name ("Name" specified inside the RPM .spec configuration file), not the RPM file name itself. So, for application "foo" we have the foo.spec configuration file with the package name defined as "lsb-foo". The user would install "foo.rpm", but would see "lsb-foo" in the system's software registry. In short, there are no "lsb" *file* prefix or suffix. The LSB's specified RPM v3 file format (with restrictions) is just simply a dumbed down RPM file that both RPM and DEB systems can handle. Did I help clarify anything, or am I not understanding the question correctly? George (gk4)
