File conflict /usr/lib64 installing rpm built with rpmbuild

[seasonedgeek (Roland Hughes)]

All,

I’m trying to create a stand-alone RPM package of CopperSpice. Already have all of the Debian packaging done. I use this for RedDiamond and was previously thumping everything in under OPT. Now I’m busting the packages out into their own RPMs and putting them in proper system directories. I’m not a complete Newb to RPMBUILD, but I am a Newb to this error and how to fix it.

It’s not a “file” conflict. The default action for RPMBUILD (and one of the reasons I like it) is if you put /usr in your .spec file (and your build actually puts things there) is that it finds and does everything for you.

When I run

rpm -qpl my.rpm

on the generated rpm I see the following:

…

/usr/lib/.build-id/f7/5f0173fd01e2bb844e138f740b6d9db759153f
/usr/lib/.build-id/f7/9ee405efa0679693826cb848042d8f1d7fee66
/usr/lib64
/usr/lib64/cmake
/usr/lib64/cmake/CopperSpice
/usr/lib64/cmake/CopperSpice/CopperSpiceBinaryTargets-release.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceBinaryTargets.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceConfig.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceConfigVersion.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceDeploy.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceLibraryTargets-release.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceLibraryTargets.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceMacros.cmake
/usr/lib64/cmake/CopperSpice/InstallMinGW.cmake
/usr/lib64/copperspice
/usr/lib64/copperspice/bin
/usr/lib64/copperspice/bin/lconvert
/usr/lib64/copperspice/bin/linguist
/usr/lib64/copperspice/bin/lrelease
/usr/lib64/copperspice/bin/lupdate
/usr/lib64/copperspice/bin/rcc
/usr/lib64/copperspice/bin/uic
/usr/lib64/copperspice/plugins
/usr/lib64/copperspice/plugins/imageformats
/usr/lib64/copperspice/plugins/imageformats/CsImageFormatsSvg1.8.so
/usr/lib64/copperspice/plugins/mediaservices
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_audiodecoder1.8.so
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_camerabin1.8.so
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_mediaplayer1.8.so

…

The existence of /usr/lib64 should not be causing this error, but apparently is. Forcing people to do this:

is a recipe for disaster. Always was which is why the RPMBUILD default behavior became “include everything under the directory”

Is there a better work around that doesn’t require a user to -force an install?

[mattdm (Matthew Miller)]

If the permissions or ownership don’t match, there will be a conflict.

[seasonedgeek (Roland Hughes)]

Well, this is created by the RPMBUILD utility. It creates the build tree and it adds /usr/lib64 and it sets owner + attributes.

If I do this maintenance-disaster-waiting-to-happen

I can avoid the conflict and get the these files.

/usr/lib/.build-id/f7/9ee405efa0679693826cb848042d8f1d7fee66
/usr/lib64/cmake
/usr/lib64/cmake/CopperSpice
/usr/lib64/cmake/CopperSpice/CopperSpiceBinaryTargets-release.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceBinaryTargets.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceConfig.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceConfigVersion.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceDeploy.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceLibraryTargets-release.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceLibraryTargets.cmake
/usr/lib64/cmake/CopperSpice/CopperSpiceMacros.cmake
/usr/lib64/cmake/CopperSpice/InstallMinGW.cmake
/usr/lib64/copperspice
/usr/lib64/copperspice/bin
/usr/lib64/copperspice/bin/lconvert
/usr/lib64/copperspice/bin/linguist
/usr/lib64/copperspice/bin/lrelease
/usr/lib64/copperspice/bin/lupdate
/usr/lib64/copperspice/bin/rcc
/usr/lib64/copperspice/bin/uic
/usr/lib64/copperspice/plugins
/usr/lib64/copperspice/plugins/imageformats
/usr/lib64/copperspice/plugins/imageformats/CsImageFormatsSvg1.8.so
/usr/lib64/copperspice/plugins/mediaservices
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_audiodecoder1.8.so
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_camerabin1.8.so
/usr/lib64/copperspice/plugins/mediaservices/CsMultimedia_gst_mediaplayer1.8.so
/usr/lib64/copperspice/plugins/platforms
/usr/lib64/copperspice/plugins/platforms/CsGuiXcb1.8.so
/usr/lib64/copperspice/plugins/playlistformats
/usr/lib64/copperspice/plugins/playlistformats/CsMultimedia_m3u1.8.so
/usr/lib64/copperspice/plugins/printerdrivers
/usr/lib64/copperspice/plugins/printerdrivers/CsPrinterDriverCups1.8.so
/usr/lib64/copperspice/plugins/xcbglintegrations
/usr/lib64/copperspice/plugins/xcbglintegrations/CsGuiXcb_Glx1.8.so
/usr/lib64/libCsCore1.8.so
/usr/lib64/libCsGui1.8.so
/usr/lib64/libCsMultimedia1.8.so
/usr/lib64/libCsNetwork1.8.so
/usr/lib64/libCsOpenGL1.8.so
/usr/lib64/libCsScript1.8.so
/usr/lib64/libCsSql1.8.so
/usr/lib64/libCsSvg1.8.so
/usr/lib64/libCsWebKit1.8.so
/usr/lib64/libCsXcbSupport1.8.so
/usr/lib64/libCsXml1.8.so
/usr/lib64/libCsXmlPatterns1.8.so
/usr/share
/usr/share/doc
/usr/share/doc/copperspice
/usr/share/doc/copperspice/copperspice
/usr/share/doc/copperspice/copperspice/LICENSE
/usr/share/doc/copperspice/copperspice/LICENSE/LGPL_EXCEPTION.txt
/usr/share/doc/copperspice/copperspice/LICENSE/LICENSE.FDL
/usr/share/doc/copperspice/copperspice/LICENSE/LICENSE.LGPL

Is Fedora breaking with Linux tradition and now trying to force all libraries vendors to put all libraries in /usr/lib/library_name?

I still believe this is an rpmbuild bug on Fedora. It chose to add /usr/lib64 all on its own and that caused the install gag.

I was able to successfully install the maintenance nightmare package.

[mattdm (Matthew Miller)]

@seasonedgeek

Well, this is created by the RPMBUILD utility.

I honestly have no idea what “the RPMBUILD utility” is.

@seasonedgeek

Is Fedora breaking with Linux tradition and now trying to force all libraries vendors to put all libraries in /usr/lib/library_name?

No.

Like I said, the file conflict is likely due to a difference in permissions for the common files owned by both the package you have created and the normal filesystem package. See File and Directory Ownership in the Fedora Packaging Guidelines for details.

This is not new. If you were doing this before and it worked, I’m not sure exactly what might have changed. But it wasn’t anything malicious — the basics have been like this for many years.

[vwbusguy (Scott Williams)]

@mattdm

I honestly have no idea what “the RPMBUILD utility” is.

I use rpmbuild to build RPMs locally (assuming it’s the command). Pretty sure this is what mock, koji, etc. are probably using for a lower level tool.

Otherwise, yeah, it’s the same spec rules for any other RPM build system.

These should almost certainly not be in the file list for the RPM spec:

/usr/lib64
/usr/lib64/cmake

[vgaetera (Vladislav Grigoryev)]

The Fedora Packaging Guidelines recommend using RPM macros like %{_libdir} and specifically mention exceptions for directory ownership:

Packages must own all directories they put files in, except for:

• any directories owned by the filesystem, man, or other explicitly created -filesystem packages
• any directories owned by other packages in your package’s natural dependency chain

[mattdm (Matthew Miller)]

@vwbusguy

I use rpmbuild to build RPMs locally (assuming it’s the command). Pretty sure this is what mock, koji, etc. are probably using for a lower level tool.

Oh — I assumed by the use of all caps that this was some other higher-level wrapper someone had made.

@seasonedgeek Assuming that’s the case, it seems that what you want to do is not actually own that higher-level directory, but rather not have to worry about files appearing and disappearing between upstream releases.

The suggested (and typical) practice is to use wildcards which are likely to match files which do belong, but won’t include those which don’t. That way, if a build error causes some junk to be dumped somewhere, you’ll get an error and can fix that.

For example, in your example, it looks like %{libdir}/libCs*.so (plus the various directories that do properly belong to the package) would do it.

[seasonedgeek (Roland Hughes)]

@mattdm et-all

While this is all well and good, it is still a bug in rpmbuild or more directly a bug in Fedora implementation of it.

By default rpmbuild looks in /usr of the BUILDROOT directory and includes everything there. It is the one adding /usr/lib64 then adding all of the entries below it. While it does set the attributes correctly the generated RPM throws the error on Fedora when you try to install it. I don’t have a SuSE VM ready for testing, but I suspect it doesn’t throw an error there because it never did.

While @vgaetera quote is correct, it is subject to invalid interpretation. That RPM (I looked inside) did set the ownership and attributes correctly to match filesystem. I have had many other RPMs that include the root directories just fine. The problem with Fedora appears to be this fine fine fickle finger of fate.

Fedora linked bin, lib, lib64, and sbin down a level to the real /usr directories. RPMs that have any of those simply cannot be installed.

I have created and installed RPMs with opt, etc, var, and several other directories just fine. The prior version of this very RPM installed everything under opt and rpmbuild had opt in the RPM.

The nice part about rpmbuild automatically including everything under BUILDROOT/usr was that later versions of any package could add things to libexec, local, share et-all that weren’t in the first release, and not have any maintenance issues.

[mattdm (Matthew Miller)]

@seasonedgeek

By default rpmbuild looks in /usr of the BUILDROOT directory and includes everything there. It is the one adding /usr/lib64 then adding all of the entries below it.

Maybe it would help if you post your specfile. Are you saying that you’re not including anything in %files and expect rpmbuild to include everything in /usr? This is not its standard behavior.

@seasonedgeek

. That RPM (I looked inside) did set the ownership and attributes correctly to match filesystem. I have had many other RPMs that include the root directories just fine. The problem with Fedora appears to be this fine fine fickle finger of fate.

Sometimes computers are surprising, but there’s usually a reason. Your screenshot does not show the permissions and ownership of /usr/lib and /usr/lib64 in your package (or on your system, for that matter).

@seasonedgeek

Fedora linked bin, lib, lib64, and sbin down a level to the real /usr directories. RPMs that have any of those simply cannot be installed.

This was done over a decade ago: Features/UsrMove - Fedora Project Wiki. Note that upstream systemd plans to remove support for not doing it this way later this year.

@seasonedgeek

The nice part about rpmbuild automatically including everything under BUILDROOT/usr was that later versions of any package could add things to libexec, local, share et-all that weren’t in the first release, and not have any maintenance issues.

I as I noted before, we suggest using at least wildcards in the file list so that if file changes aren’t what you expect, it can be caught automatically.

In general, rpmbuild in Fedora is meant to build packages in ways that conform to our packaging guidelines. RPM is very flexible and can do a lot of things, but not everything that can be done should be done.

From what I’ve seen so far, the problem you are encountering still seems likely to be because of the metadata for /usr/lib and /usr/lib64 in your RPM. As we’ve said, it would be better practice for your package to not own these, and there are several ways in which you can make that happen. But you should also be able to correct this and keep doing what you’re doing, if you really want.

[vekruse (Villy Kruse)]

@mattdm

From what I’ve seen so far, the problem you are encountering still seems likely to be because of the metadata for /usr/lib and /usr/lib64 in your RPM. As we’ve said, it would be better practice for your package to not own these, and there are several ways in which you can make that happen. But you should also be able to correct this and keep doing what you’re doing, if you really want.

If you look at fedora provides packages, /usr/lib and /usr/lib64 are owned by the filesystem package and no other packages owns those directories.

[seasonedgeek (Roland Hughes)]

@mattdm

I realize you are fixated on the “not Fedora problem” train of thought, but this is most definitely a Fedora problem.

I had

%files
/usr

been doing that for years.

rpmbuild took it upon itself to add

/usr/lib64

all by itself followed by setting of attributes.

I don’t have the RPM file. I would have to jury rig the .spec.in file and kick off another 3.5 hour build to recreate the file.

rpmbuild stuck that in all by itself. Obviously been a bug in the Fedora world for a very long time since everybody is saying to use

/usr/lib64/lib*

That’s a work-around hack.

rpmbuild should not be adding a naked parent directory. On all other distros I’ve tried the stuff on, having the naked parent is never a problem. It doesn’t overwrite anything and doesn’t get removed when un-installing.

On Fedora it’s a problem. Been a problem long enough that the work-around hack of full pathing is considered a “best practice”, it’s not. It’s a maintenance nightmare and a disaster waiting to happen.

Ordinarily I build Linux systems for medical devices. Granted most use Yocto and are not an RPM derivative, but not all. This report here is the first time I’ve ever encountered this issue.

Issue:
rpmbuild when run on Fedora and possibly Fedora alone, adds naked parent directories with attr() settings in the generated package. Fedora gags on it.

It’s not “all entries in filesystem” as some proclaim, it is only the linked directories.

Your RPM can have naked entries for all other filesystem owned directories and Fedora processes the install correctly. For years now I’ve been having this with /opt and quite a few other directories.

mkdir doesn’t fail if a directory already exists.

Yes, Debian based systems like Ubuntu have already added links as well.

When a Debian package has a naked parent dir like /usr/lib64, the install doesn’t fail. It correctly ignores it as “being there for documentation” and moves on.

I understand you and others want to keep beating the filesystem drum, but it’s a false argument. You can have a naked opt in your RPM and things install just fine. It’s only the link targets that are hosed.

Yes, I’m going to have to use the work-around hack that is now incorrectly branded as a “best practice.” Yes, three seconds down the road it will become a maintenance debacle because things that get added to a “package” and tested won’t physically get added to the package everyone else gets.

[vwbusguy (Scott Williams)]

@seasonedgeek

I realize you are fixated on the “not Fedora problem” train of thought

This kind of escalating language isn’t going to help your problem get solved. I strongly recommend that you take up Matthew’s suggestion to post a link to your spec file here. The solution could be as simple as removing two lines from the %files section as I suggested here:

File conflict /usr/lib64 installing rpm built with rpmbuild

I use rpmbuild to build RPMs locally (assuming it’s the command). Pretty sure this is what mock, koji, etc. are probably using for a lower level tool. Otherwise, yeah, it’s the same spec rules for any other RPM build system. These should almost certainly not be in the file list for the RPM spec: /usr/lib64 /usr/lib64/cmake

But without a spec file, we’re effectively flying blind otherwise to help you get this patched. Keep in mind that rpmbuild appears to be building it correctly per your specs, but rpm is (rightfully) failing to install it as it is conflicting with other rpms. This is a case where “best practices” are helping you fix something that can’t reasonably be done. It’s “best practice” to not breathe water. That doesn’t mean that if you try anyway and it goes very badly, that there is an inherent problem with the implementation of your lungs. rpm was designed with a certain level of sanity in mind and these specific “best practices” are also being enforced by rpm itself, which isn’t solely a Fedora thing. I expect this to likewise fail the exact same way in OpenSuSE.

[vgaetera (Vladislav Grigoryev)]

@seasonedgeek

I had

%files
/usr

been doing that for years.

But the world does not stand still.
Guidelines and standards change and adapt to modern challenges.
If you ignore the official recommendations, there’s nothing unusual that something does not work as expected.

@seasonedgeek

since everybody is saying to use

/usr/lib64/lib*

There’s a special warning against using globs carelessly:

Shared libraries installed directly into %{_libdir} SHOULD NOT be listed in the %files section of the spec by using a glob in a way that conceals important parts of the file name (e.g. libfoo.so* ), since changes to the SONAME also result in a changed file name in most cases.

[mattdm (Matthew Miller)]

@seasonedgeek

%files
/usr

been doing that for years.

Okay. That is incompatible with Fedora packaging guidelines. If you want to build a package for Fedora Linux, don’t do that. It probably won’t work. If it worked at one point, it is unlikely to work at some point in the future.

I know you want to do this for ease of maintenance.

1. We actually recommend not doing that (see the packaging guidelines again), because in the end we think the risk of problems is greater than the work saved, but
2. there actually are several ways you could get the same effect (include whatever is built, wherever it lands, no questions asked) without the problem you are encountering,
3. but you need to listen in order to learn those and solve your problem.

@seasonedgeek

Obviously been a bug in the Fedora world for a very long time since everybody is saying to use

/usr/lib64/lib*

That’s a work-around hack.

I don’t think anyone is saying to do that. I mean, you could, but … you probably shouldn’t. Really.

@seasonedgeek

Yes, I’m going to have to use the work-around hack that is now incorrectly branded as a “best practice.” Yes, three seconds down the road it will become a maintenance debacle because things that get added to a “package” and tested won’t physically get added to the package everyone else gets.

This seems like hyperbole. Do you want practical help with your packaging effort, or do you want to score theoretical points with some sort of imaginary judging body?

[seasonedgeek (Roland Hughes)]

@vwbusguy

these specific “best practices” are also being enforced by rpm itself, which isn’t solely a Fedora thing. I expect this to likewise fail the exact same way in OpenSuSE.

They aren’t “best practices” and your suspicion would be incorrect. I didn’t fail until I got to Fedora.

Hey, you don’t want to fix Fedora, I’m fine with that. I am more than happy to release an RPM that installs everywhere except Fedora. If Fedora users want to use the stuff they can install an AppImage. I reported the issue. If the report gets ignored that is not my problem.

Sorry to have come here.

[vwbusguy (Scott Williams)]

@seasonedgeek

I am more than happy to release an RPM that installs everywhere except Fedora.

Again, if you can post a link to your spec file here, it would be very helpful for us to help you get your package working. Please keep in mind that most of us here, like myself, are volunteers and aren’t paid to be here. You’ll be a lot more likely to get better results if you consider that this is a community distribution and not one that inherently owes you something. If you would rather your stuff not run on Fedora, that’s entirely your call to make. That said, it seems like that doesn’t need to be the case, but there’s little we can do to help from here if you’re unwilling to share your spec file with us.