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?

up vote 3 down vote accepted

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")

Sources:

  • 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 Apr 16 '14 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 Apr 18 '14 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. – Pavel Šimerda Apr 21 '14 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 Apr 22 '14 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 Apr 28 '14 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 Apr 28 '14 at 18:48

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.