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?
Improve this question
3
  • 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, 2015 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, 2015 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, 2016 at 1:44

1 Answer 1

Reset to default
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.

Improve this answer
2
  • Thanks. When you say compiled java classes, are you referring to jar files as well?
    – kaizenCoder
    May 23, 2015 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, 2015 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .