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

"autolibs": RVM install fails on Arch if gcc-multilib package is installed #1770

Closed
epitron opened this Issue Apr 6, 2013 · 11 comments

Comments

Projects
None yet
3 participants
@epitron

epitron commented Apr 6, 2013

On Arch, when installing Ruby, RVM's autolibs is only looking for the gcc package. However, the gcc-multilib package is also a valid provider of gcc.

(The "multilib" repositories allow users to run 32-bit binaries on a 64-bit distro.)

autolibs should be checking for the presence of gcc or gcc-multilib.

@ghost ghost assigned envygeeks Apr 6, 2013

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Apr 6, 2013

Contributor

Does gcc-multilib not bring in gcc/gcc-* (via gcc) and gcc-*-multilib via a Meta package in Arch?

Contributor

envygeeks commented Apr 6, 2013

Does gcc-multilib not bring in gcc/gcc-* (via gcc) and gcc-*-multilib via a Meta package in Arch?

@epitron

This comment has been minimized.

Show comment
Hide comment
@epitron

epitron Apr 6, 2013

Yes, gcc-multilib does "provide" gcc, but apparently autolibs doesn't know how to look up those virtual provides.

epitron commented Apr 6, 2013

Yes, gcc-multilib does "provide" gcc, but apparently autolibs doesn't know how to look up those virtual provides.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Apr 6, 2013

Contributor

Ah okay, I assume we can adjust autolibs to actually be a little smarter in that area, possibly fall back to a which so that we even support custom builds of certain packages outside of the package manager. What say you to this idea @mpapis?

Contributor

envygeeks commented Apr 6, 2013

Ah okay, I assume we can adjust autolibs to actually be a little smarter in that area, possibly fall back to a which so that we even support custom builds of certain packages outside of the package manager. What say you to this idea @mpapis?

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Apr 6, 2013

Member

we have few options:

  1. which gcc - very simplistic and I do not like it that much as it can have false positives
  2. make the search detect one of many packages like we already do in few places
  3. make search detect virtual packages / provides

@epitron we currently use:

requirements_arch_lib_installed()
{
  pacman -Q "${1}" >/dev/null || return $?
}

to search for packages, could it be improved to also search (fast) for virtual packages / provides mentioned in 3.?

Member

mpapis commented Apr 6, 2013

we have few options:

  1. which gcc - very simplistic and I do not like it that much as it can have false positives
  2. make the search detect one of many packages like we already do in few places
  3. make search detect virtual packages / provides

@epitron we currently use:

requirements_arch_lib_installed()
{
  pacman -Q "${1}" >/dev/null || return $?
}

to search for packages, could it be improved to also search (fast) for virtual packages / provides mentioned in 3.?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Apr 6, 2013

Contributor

I don't understand how which can provide a false positive unless you are sloppy with the query somehow.

Contributor

envygeeks commented Apr 6, 2013

I don't understand how which can provide a false positive unless you are sloppy with the query somehow.

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Apr 6, 2013

Member

pure which gcc would find 64bit gcc even we need 32bit - like in the planned 32bit support, otherwise that should work too - but the package manager check seems to be more reliable way of detecting proper gcc.

Member

mpapis commented Apr 6, 2013

pure which gcc would find 64bit gcc even we need 32bit - like in the planned 32bit support, otherwise that should work too - but the package manager check seems to be more reliable way of detecting proper gcc.

@epitron

This comment has been minimized.

Show comment
Hide comment
@epitron

epitron Apr 7, 2013

@mpapis I checked pacman's manpage, and dependency testing is done with pacman -T <real or virtual package>. It is silent and returns 0 if successful, and lists not-installed dependencies and returns non-zero values on failure.

epitron commented Apr 7, 2013

@mpapis I checked pacman's manpage, and dependency testing is done with pacman -T <real or virtual package>. It is silent and returns 0 if successful, and lists not-installed dependencies and returns non-zero values on failure.

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Apr 7, 2013

Member

@epitron so assuming you have only gcc-multilib installed the following:

pacman -T gcc >/dev/null && echo installed || echo missing

will print installed, does it?

Or there is other virtual package that provides gcc?

Member

mpapis commented Apr 7, 2013

@epitron so assuming you have only gcc-multilib installed the following:

pacman -T gcc >/dev/null && echo installed || echo missing

will print installed, does it?

Or there is other virtual package that provides gcc?

@epitron

This comment has been minimized.

Show comment
Hide comment
@epitron

epitron Apr 7, 2013

That is correct. And if I change gcc to gccasjdhf, it prints "missing". :)

epitron commented Apr 7, 2013

That is correct. And if I change gcc to gccasjdhf, it prints "missing". :)

@epitron

This comment has been minimized.

Show comment
Hide comment
@epitron

epitron Apr 7, 2013

I think this would be more efficient, btw, since pacman can do all the dependency testing at once:

MISSING_PACKAGES="`pacman -T pkg1 pkg2 pkg3`"

if [ "$MISSING_PACKAGES" != "" ]; then
  echo "Installing missing packages..."
  pacman -S $MISSING_PACKAGES
fi

epitron commented Apr 7, 2013

I think this would be more efficient, btw, since pacman can do all the dependency testing at once:

MISSING_PACKAGES="`pacman -T pkg1 pkg2 pkg3`"

if [ "$MISSING_PACKAGES" != "" ]; then
  echo "Installing missing packages..."
  pacman -S $MISSING_PACKAGES
fi

@mpapis mpapis closed this in 949f2a1 Apr 7, 2013

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Apr 7, 2013

Member

rescheduling the change to 1.20 as it's bigger change and it should work in most cases before the change - or are there any reasons to have it in 1.19.2?

Member

mpapis commented Apr 7, 2013

rescheduling the change to 1.20 as it's bigger change and it should work in most cases before the change - or are there any reasons to have it in 1.19.2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment