I'm building some rpm packages and checking for standards and style conformance using rpmlint. The packages are specific to systems at my place of work and they won't get pushed upstream. Our packages include a variety of software, including in-house software, patched versions of software from the repositories, and software not available from the official repositories. We install local packages into /usr/local for many reasons:

  • avoids naming conflicts with official packages
  • prevents yum update from clobbering local packages
  • allows local packages to live on separate partition or disk and/or be shared over NFS so that packages and configurations can be shared among hosts
  • allows us to have greater control over packages that are installed from sources outside the official repository, many of which do not conform to the standard installation paths (bin, lib, include, share, etc.)

However, rpmlint gets very complainy when run on a package that installs files to /usr/local. For instance, on a custom build of GNU Hello World, this is what rpmlint -i has to say:

hello.x86_64: E: dir-or-file-in-usr-local /usr/local/hello-2.8/bin/hello
A file in the package is located in /usr/local. It's not permitted for
packages to install files in this directory.

I'm aware of the filesystem hierarchy standard, according to which:

The original idea behind '/usr/local' was to have a separate ('local') '/usr' directory on every machine besides '/usr', which might be just mounted read-only from somewhere else. It copies the structure of '/usr'. These days, '/usr/local' is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

We are, in fact, following these standards and installing our local software to /usr/local for just these reasons, so I don't see why there should be anything wrong with using a package manager to install packages to /usr/local. However, I'd also like our packages to be standards-compliant, if for no other reason than consistency among our local packages. So why does rpmlint throw an error for files in /usr/local? Shouldn't this be at the packager's descretion? Can I ignore this error or at least make rpmlint print a warning instead?

2 Answers 2


rpmlint is a tool to check RPMs against some sort of packaging policy. Its configuration is typically distribution dependant and it checks packages against the particular distribution policy. Checking your own packages is fine as long as this is what you want.

If your policy differs from the distribution policy, you either have to configure rpmlint accordingly, refrain from using it or ignore the specific errors.

The following should do the trick when added to /etc/rpmlint/config or ~/.config/rpmlint (not tested):

addFilter("E: dir-or-file-in-usr-local")


  • This partially answered my question. How do I configure rpmlint to change its /usr/local policy? I haven't been able to figure this out through man pages or through google. I've only been able to figure out that I'll probably need to set an option in /etc/rpmlint/config, but that file only contains a one-line header on my system.
    – jayhendren
    Commented Apr 16, 2014 at 22:08
  • ah, thank you for the edit. I don't know how I didn't see it earlier, but this answers my question. I haven't tested it yet, but I'm accepting this answer because it's putting me on the right track.
    – jayhendren
    Commented Apr 18, 2014 at 16:59

You are not following the standard. /usr/local is designed to contain locally compiled files, i.e. files built in the local machine.

When you create a package, the goal is to distribute it to other machines.

Should you install your package on a machine then build the same software from source on the very same machine, the package files would be overwritten if both targets are /usr/local. This is the conflict rpmlint is trying to avoid.

In your case, I would suggest to create a package that install files under /opt/hello2.8. The latter directory wouldn't conflict with either an upstream package or locally built files.

  • I noted the downvote here but I don't think jlliagre's answer is wrong. While my answer says how to do it, his answer says what to do instead which is IMO valid in this case. Voting up. Commented Apr 21, 2014 at 15:08
  • @PavelŠimerda Thanks for understanding my point. The question was "Why is this an error" and I believe I explained why it is indeed one. I would appreciate the downvoter to comment here about why (s)he disagree.
    – jlliagre
    Commented Apr 22, 2014 at 16:35
  • I did not vote for this answer because this part of my question was not answered: "Can I ignore this error or at least make rpmlint print a warning instead?" Also, you answered the first part of my question correctly, but you also seemed to answer a different question that I did not ask, which might be phrased as "How can I follow the standard policy that rpmlint enforces?"
    – jayhendren
    Commented Apr 28, 2014 at 17:55
  • I answered to the question you choose as title "Why is “dir-or-file-in-usr-local” an error rather than a warning?" which is assumed to be the main question. The remaining of my answer were to help you understand that your assumption "We are, in fact, following these standards" is incorrect and to meet your request "However, I'd also like our packages to be standards-compliant". It you are the downvoter, that is quite an unfair attitude.
    – jlliagre
    Commented Apr 28, 2014 at 18:48
  • Is this specified Commented Jun 21, 2022 at 11:59

You must log in to answer this question.

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