Is There a Rpm File Naming Convention in Lsb

Is there a RPM File naming convention in LSB?

In the relevant section of the "LSB Book", Packaging, it's only required

• to prefix your package with lsb-
• to register the portion of your package name up to the first hyphen in LANANA (or for it to be your domain name).

However, the standard LSB packaging tool wrapper, makelsbpkg, is said to generate package names in the form mypackage-1.0.0-1.%arch.rpm, which, I guess is the name-version-release.architecture.rpm scheme you linked to.

(I think, it's intended that package name (mypackange in the example above, already contains lsb- prefix. I'm not sure, never actually ran the tool.)

What does sdl6 in an RPM package name refer to?

That's the distro tag (for CentOS normally el#). In this case sdl appears to be for Springdale Linux.

Packaging proprietary software for Linux

Generic issues

Your way to package your stuff (with dependent libs) to /opt is how proprietary (and even open-source) software is packaged. It's recommended practice of The Linux Foundation (see my answer to the other question for links).

External libs may be either compiled from scratch and embedded into your build process as a separate step (especially if you modify them), or fetched from packages of some distributions. The second approach is easier, but the first one allows more flexibility.

Note that it's not necessary to include some really low-level libraries (such as glibc, Xorg) into your package. They'd be better left to system vendors to tune, and you may just assume they exist. Moreover, there's an Linux Standard Base, that documents the most important libraries; these libraries exist almost everywhere, and can be trusted.

Note also that if you compile under a newer system, most likely, users of older systems won't be able to use it, while the reverse is not true. So, to reach better compatibility, it might be useful to compile package under a system that's two years older than today.

I just outlined some generic stuff, but I believe that Linux Developers Network website contains more information about packaging and portability.

Packaging

Judging by what I saw in the open-source distribution projects, your script does it the same way distribution vendors package software. Their scripts automatically patch sources, mimic installation of software and package the resultant folders into DEBs and RPMs.

Tar.gz, or course, could also work, but creating, for example, an RPM is not complex enough for you to miss such an opportunity to make life of your users so much easier.

Answering your questions,

• Yes, you have to hard-code dependencies twice.

  The thing is that when you hardocde them in CMake, you specify them in the other terms than when you specify them in a packaging script. CMake refers to shared libraries and header files, while packaging script refers to packages.

  There's no cross-distribution one-to-one relationship between package names and shared libs and headers. It varies through distributions. Therefore, it should be specified twice.

  But the package can be easily re-packed by distribution vendors, especially if you strive to packing all dependent libs into it (so there'll be less external dependencies to port). Also, a tool that can port packages from one distribution to another will appear soon (I'll update my answer when it's released).

• Yes, you have to specify your version twice.

  But the thing is that you may organize your packaging process in such a way that package and software versions never get out-of-sync. Just make the packaging script check out from your repository (or download from your website) exactly the same version that the script will write to package specifications.

Analyzing Dependencies

To analyze dependencies of your software, you may use our open-source, free Linux Application Checker tool. It will report the list of libraries it depends on, show distributions your software is compatible with, and help your application be more portable across distributions. It turns out that sometimes more cross-distribution compatibility can be achieved by little effort, and you don't have to lock yourself into support of just a few selected distributions.

Generating aarch64 RPM package from yocto SDK

The variable CPACK_RPM_PACKAGE_ARCHITECTURE defaults to uname -m which is currently set to the architecture of your computer. You can manually set this variable to override the package architecture.

CPACK_RPM_PACKAGE_ARCHITECTURE=aarch64 cpack -G "RPM"

Why RPM is better than DEB for MeeGo?

RPM is specified as the packaging format for the Linux Standard Base.

...

Okay, I admit it, that's stretching for an answer, even for me. There isn't an awful lot of difference in the base purpose of both RPM and DEB packages; they each have their own distinct capabilities, but in the end they're both a bag of files and metadata.

---

Related Topics