Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Omnibus RPM Owns Directory in Filesystem Package #663

Closed
eoly opened this issue Apr 8, 2016 · 7 comments · May be fixed by #665
Closed

Omnibus RPM Owns Directory in Filesystem Package #663

eoly opened this issue Apr 8, 2016 · 7 comments · May be fixed by #665

Comments

@eoly
Copy link

eoly commented Apr 8, 2016

Description

RPMs built by Omnibus are claiming ownership of directories owned by the filesystem package resulting in conflicts when installing the RPM on a Centos 7 system.

I think this may be a regression back to the behavior of Omnibus prior to PR #392

It appears the regression was introduced in this commit: 160389f

Omnibus Version

omnibus (5.3.0)

Platform Version

CentOS Linux release 7.2.1511 (Core)

Replication Case

Perform Steps on CentOS 7 VM or Docker Container

Build Test Omnibus Package

Run rpm -qpl on the resulting RPM and you will see the RPM claims ownership of the /lib directory.

[root@localhost pkg]# rpm -qpl test-0.0.0+20160408161743-1.el7.x86_64.rpm
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/thing.service
/opt
/opt/test
/opt/test/LICENSE
/opt/test/LICENSES
/opt/test/bin
/opt/test/embedded
/opt/test/embedded/bin
/opt/test/embedded/lib
/opt/test/version-manifest.json
/opt/test/version-manifest.txt

Trying installing the rpm with rpm -ivh

[root@localhost pkg]# rpm -ivh test-0.0.0+20160408161743-1.el7.x86_64.rpm
Preparing...                          ################################# [100%]
    file /lib from install of test-0.0.0+20160408161743-1.el7.x86_64 conflicts with file from package filesystem-3.2-20.el7.x86_64

/cc @chef/omnibus-maintainers <- This ensures the Omnibus Maintainers team are notified to review this PR.
@schisamo
Copy link
Contributor

It sounds like we need to update:
https://github.com/chef/omnibus/blob/master/resources/rpm/filesystem_list

Can you run the following command and share the output:

rpm -ql filesystem-3.2-20.el7.x86_64

Feel free to just open a PR with the required changes.

@eoly eoly mentioned this issue Apr 12, 2016
Open
@eoly
Copy link
Author

eoly commented Apr 12, 2016

Updating filesystem_list based on the output of rpm -ql filesystem-3.2-20.el7.x86_64 did not resolve the issue. I created PR #665 just in case you want to update the list anyways.

I was able to fix this issue by making a code change. I'm going to create a PR with that change shortly.

@eoly eoly mentioned this issue Apr 12, 2016
Open
@eoly
Copy link
Author

eoly commented Apr 12, 2016

With the change in #666 I'm able to build my test omnibus package without conflicts with the filesystem package.

[root@localhost pkg]# rpm -qpl test-0.0.0+20160412025509-1.el7.x86_64.rpm
/lib/systemd
/lib/systemd/system
/lib/systemd/system/thing.service
/opt/test
/opt/test/LICENSE
/opt/test/LICENSES
/opt/test/bin
/opt/test/embedded
/opt/test/embedded/bin
/opt/test/embedded/lib
/opt/test/version-manifest.json
/opt/test/version-manifest.txt

@amdprophet amdprophet mentioned this issue Jun 27, 2017
Closed
@akuzminsky
Copy link

this affects me as well. The project config includes an extra file

extra_package_file '/usr/bin/magpie'

That leads to including /usr and /usr/bin into the %files:

$ rpm -qlp magpie-0.9.0-1.el7.x86_64.rpm
...
/usr
/usr/bin
/usr/bin/magpie

@akuzminsky
Copy link

As workaround I create/delete a symlink in postinst/postrm.

@lamont-granquist
Copy link
Contributor

Closing this issue as an old issue. The issue may be some combination of:

  • Already fixed in new versions.
  • Not enough reproduction steps.
  • Not clear that the behavior is a bug.
  • Insufficient interest in the bug/feature/use-case after an extended period of time.
  • Acceptable workarounds exist (or the workarounds are more correct).
  • A help request rather than a bug report or feature request.

If this issue was a valid bug or feature request it may not rise to the level of importance were we will consider allocating resources to complete the request. The impact of fixing it may be small or trivial, while the effort required may be better spent on other issues with higher severity. It may still be acceptable to open a PR to submit the work, but closing the issue is a statement that we are not accepting the task of doing the work.

@akuzminsky
Copy link

The issue still exists in Omnibus v6.1.9. Looks like #666 is an easy fix. Is there any chance to get it merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

update filesystem_list with directories from filesystem-3.2-20.el7.x8… eoly/omnibus
4 participants
@schisamo @lamont-granquist @akuzminsky @eoly