5

Preface

By building RPMs I do not mean compiling from source code. I purely mean taking a tar or a 'zip' file with source code or binaries and repackaging it as a RPM.

I've been building RPMs from source code for a while now as noarch RPMs. Recently I've had to build RPMs that contain binaries which has raised some concerns:

  1. Is there a best practice on determining facters between arch and noarch RPMs? Specially in the event of building RPM from binary files. I understand that for pure source code where there is no compilation and only extracting files on install of RPM, noarch is acceptable however as mentioned above, I've got some doubt when it comes to packaging binaries.
  2. Are arch RPMs compatible with different OS versions? (This is in the context of the preface above) Just to elaborate can I build a arch RPM on RedHat 6 and then install it in RedHat 5 and vice versa?
kaizenCoder
  • 537
  • 4
  • 8
  • 15
  • Speaking of (2), I doubt that. I.e. package for EL6 may rely on some Python library, which only present in 2.7. And all packages with python code only are tagged as `noarch`. – myaut May 21 '15 at 12:05
  • @myaut: Updated my question. This might seem trivial but if the RPM is built via a tar file will with no compilation however contains binary files, is it still not recommended to use the RPM across versions? – kaizenCoder May 21 '15 at 22:44
  • I think if you use rpmlint on your RPMs they'll warn you if you get the ARCH wrong – Rich Homolka Jun 10 '16 at 01:44

1 Answers1

8

In practice, it doesn't really matter whether you build it from source or package some pre-existing archive.

noarch RPMs are meant to be architecture-neutral, i.e., they must contain no (native) binaries.
If the package is comprised of interpreted scripts (Bash, Python, etc.), documentation, headers, media files, etc, even compiled Java classes, then it can be noarch. The same package will work on any hardware architecture because it contains no code built specifically for a given architecture.

On the other hand, if the package contains binaries that are compiled to native machine code (e.g. programs written in C, C++, Pascal, etc.), no matter what else they contain, they must be tied to an architecture. A program compiled for x86_64 can't be run on a ppc host OS, for instance.

As for being compatible with different OS versions, that will vary with dependencies, and can't be generalised easily. For example, if a package depends on a minimum version of a given library, then obviously it won't be guaranteed to work on systems with older versions of such library (or systems with no such library at all). If it has no dependencies or very generic ones then it's likely to work.
Also, strictly speaking, this applies to both arch and noarch packages.

outlyer
  • 1,093
  • 7
  • 11
  • Thanks. When you say compiled java classes, are you referring to jar files as well? – kaizenCoder May 23 '15 at 23:30
  • @aspiringCodeArtisan Yes, jars contain `class` files and accompanying data (and are actually zip files), so they are no different than those files on their own. – outlyer May 23 '15 at 23:33