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.

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

naming of /usr/sbin/packer conflicts with hashicorp packer utility #7

Closed
jeremyeder opened this issue May 2, 2016 · 14 comments
Closed

naming of /usr/sbin/packer conflicts with hashicorp packer utility #7

jeremyeder opened this issue May 2, 2016 · 14 comments

Comments

@jeremyeder
Copy link

@jeremyeder jeremyeder commented May 2, 2016

Hi all --

I'm following up on a request to include Hashicorp's packer tool in Fedora, and I notice there is a naming collision on the packer binary that's been tripping up some users for a few years.

The story is that cracklibs distributes a binary file called /usr/sbin/packer on Fedora and RHEL, and Packer from hashicorp is right now a single statically linked go binary called packer.

In hopes that we can include Hashicorp's packer in Fedora I am wondering how we can resolve this collision. For example, would it be possible to rename /usr/sbin/packer to /usr/sbin/packer-cracklibs ?

@GeorgeSapkin
Copy link

@GeorgeSapkin GeorgeSapkin commented Nov 7, 2016

/usr/sbin/packer already points to /usr/sbin/cracklib-packer so there's no need in renaming. Maybe removing the symlink is an option?

@jandd
Copy link
Contributor

@jandd jandd commented Nov 7, 2016

Just as a data point: the Debian cracklib-runtime package does contain /usr/sbin/cracklib-packer and no packer symlink so there is prior art that cracklib does not depend on a binary named packer (see https://packages.debian.org/jessie/amd64/cracklib-runtime/filelist)

@jgallucci32
Copy link

@jgallucci32 jgallucci32 commented Jan 30, 2017

Just came across this issue; pretty annoying. Upgraded from RHEL6 to RHEL7 and now my packer builds are failing due to /usr/local/sbin being in the PATH before /usr/local/bin where I keep the packer (Hashicorp) binary.

I recommend the symlink be removed permantently as well. It did not exist in RHEL6 no reason to create a conflicting binary in RHEL7.

@tomato42
Copy link

@tomato42 tomato42 commented Jan 31, 2017

Please contact Red Hat customer support directly about issues in RHEL packages.

@wayneworkman
Copy link

@wayneworkman wayneworkman commented Mar 8, 2017

I too have this issue, both on RHEL 7 and CentOS 7. Removing the symbolic link doesn't seem to work.

@fernandotower
Copy link

@fernandotower fernandotower commented Aug 18, 2017

  1. I solved this problem in fedora26 changing the file name cracklib-packer
su
mv /usr/sbin/cracklib-packer /usr/sbin/cracklib-packer_old

Other way
2. In the guide to Install Packer at the Troubleshooting section says:
To fix this, you can create a symlink to packer that uses a different name like packer.io, or invoke the packer binary you want using its absolute path, e.g. /usr/local/packer.

https://www.packer.io/intro/getting-started/install.html

@et304383
Copy link

@et304383 et304383 commented Jan 22, 2018

I just encountered this. I love how I googled only cracklib-packer and this is the first link that came up.

Clearly, this symlink isn't useful when the number one Google result is "this conflicts with the real packer"

vadorovsky added a commit to vadorovsky/packer-ci-build that referenced this issue Feb 13, 2019
Packer's binary name conflicts with cracklib's binary name[0], hence
openSUSE packaging names that binary packer-go.

[0] cracklib/cracklib#7

Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
ianvernon added a commit to cilium/packer-ci-build that referenced this issue Feb 13, 2019
Packer's binary name conflicts with cracklib's binary name[0], hence
openSUSE packaging names that binary packer-go.

[0] cracklib/cracklib#7

Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
ianvernon added a commit to cilium/packer-ci-build that referenced this issue Feb 13, 2019
Packer's binary name conflicts with cracklib's binary name[0], hence
openSUSE packaging names that binary packer-go.

[0] cracklib/cracklib#7

Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
@smakintel
Copy link

@smakintel smakintel commented Feb 28, 2019

just unlink /usr/sbin/packer will do the trick

@antoinetran
Copy link

@antoinetran antoinetran commented Oct 22, 2019

packer cracklit is an essential utility of CentOs/RedHat, we cannot even remove it with yum remove cracklib-dicts because this is used by systemd. Who can be sure that no utility in CentOs/Redhat (or Fedora) does not refers to packer as packer? Even if this is mostly a Redhat issue, I wrote this as a warning againt unlinking it. I will refers to packer with an alias in my script. As an alternative, one can use yacker ^^

@aaronk1
Copy link

@aaronk1 aaronk1 commented Nov 14, 2019

Nice, @smakintel

just unlink /usr/sbin/packer will do the trick

Has anyone seen this break something? I like the idea of this solution but I wonder what this tool does since it comes installed at this path by default on CentOS7

@jeremyeder
Copy link
Author

@jeremyeder jeremyeder commented Nov 14, 2019

I'm not working on this. Closing.

@jeremyeder jeremyeder closed this Nov 14, 2019
@antoinetran
Copy link

@antoinetran antoinetran commented Nov 14, 2019

Hi @jeremyeder ,

What made you change your mind? I still believe it would be good to avoid a name collision. Thank you.

@jeremyeder
Copy link
Author

@jeremyeder jeremyeder commented Nov 14, 2019

We're not using packer for anything anymore where the benefits of getting it into Fedora would have been helpful.

@antoinetran
Copy link

@antoinetran antoinetran commented Nov 14, 2019

@jeremyeder Are you saying that noone use packer from cracklib anymore? If yes, it would be helpful to remove /usr/sbin/packer by RPM update of cracklib, don't you agree?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet