If i emerge livecd-tools the command opengl-update do not work. gentoonet root # opengl-update /usr/sbin/opengl-update: line 8: [: `id -u`: integer expression expected /usr/sbin/opengl-update: line 34: [: $#: integer expression expected usage: opengl-update <GL implementation> note: This utility switch between OpenGL implementations. Currently there are two supported implementations, namely "xfree" and "nvidia", the implementations for XFree86 and the NVidia drivers respectively. examples: opengl-update xfree This will setup things to use libGL.so from XFree86 opengl-update nvidia This will setup things to use libGL.so from the NVidia drivers. and this package conflict with opengl-update that works fine. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I can confirm this. # qpkg -f $(which opengl-update) app-misc/livecd-tools * x11-base/opengl-update * the opengl-update came with livecd has double quote on line 8 and 34.
Come on guys, can we please get a single version of opengl-update that works either way? What can I add to x11-base/opengl-update to get it working with whatever LiveCD guys have?
OK. First off, why would someone be loading livecd-tools on their machine? They are designed for the LiveCD and *not* for general usage. I'll be honest, I grabbed that version of opengl-update simply because LiveWire was using it on the old GameCD's and I need it for the future GameCD's. The only requirement for opengl-update (on the LiveCD) is that it does not depend on python (or anything but bash, really). If there is a bug in the version provided by livecd-tools, then it needs to be assigned to livecd@gentoo.org so I can take care of it. Also, I just started the livecd herd to take over the maintenance of many of these packages, so I am unaware of any historical problems there may have been with them, so please, try to keep that in mind when making comments. If some course of action needs to be taken to move the installation location of the livecd-tools version of opengl-update, which it looks like if users are actually installing it on machines, then we should come up with a location for the new opengl-update. For now, I am hard masking >=app-misc/livecd-tools-1.0.3 to try to resolve this.
wolf: just fyi, the opengl-update your using has never been in portage, its livecd specific.
Well, livecd-tools installs opengl-setup to /sbin now. I also have livecd-tools > 1.0.2 p.masked, so I'm going to consider this one closed, but I think we need to get together and see what the livecd opengl-update does that the standard one doesn't, if anything, and add that functionality to the normal opengl-update package, even if it is only enable via USE=livecd.
Alright... I've *finally* gotten back around to this one... ;] Anyway, I've figured out what is going on with everything and looked at the latest opengl-update package. The problem is that on the LiveCD/GameCD, /usr/${LIBDIR} is not writeable, so we cannot use it for our symlinks. The current version of the opengl-update from the livecd-tools uses /etc/opengl for the symlinks and updates the environment accordingly. The only problem with the current LiveCD implementation is that it is not capable of doing the 32/64-bit stuff for amd64. Currently, most of the LiveCD is read-only, so we can only write to a few places. If we decide to write to a location that is not used for anything else, then we can simply mount it tmpfs for the LiveCD and be done with it. We can't do this for any directory containing other data, of course. So I leave this up to you guys (x11)... how do I resolve this? I would definitely like to have the 32-bit support for amd64, as the entire goal was to work towards making more GameCD releases. It doesn't look like the current /etc/opengl solution employed by livecd-tools won't work without modifications. I can easily do a /etc/opengl/lib(32/64/anything) and work from there, which will take me changing openglify and making a patch to the proper opengl-update, but that still leaves the question of how does the system know that we're running from a LiveCD and not a normal installation? I'm open to any suggestions you guys may have.
It's been suggested previously that we configure the opengl stuff in /etc rather than our current location. Apparently MDK or Suse does it like this .. some sort of double-symlink scheme.
Well, the livecd-tools uses 2 scripts, openglify, which essentially does the initial setup for having the /etc/opengl (this could be done by the opengl-update ebuild) and opengl-update, which functions identical to an older (pre 32/64-bit nvidia) other than setting all the symlinks in /etc/opengl.
Created attachment 40611 [details] openglify
Created attachment 40612 [details] opengl-update
Reassigning for x11 to integrate changes.
Also, I have renamed opengl-update to opengl-update-livecd and will be releasing a 1.1.0 version of livecd-tools with this fix in it until such time as the real opengl-update uses /etc rather than /usr/lib.
Bumping up the severity to encourage us to do something about this.
That's cool. The version of livecd-tools that I will be commiting today no longer conflicts (opengl-update-livecd), but this should still be easier if it were consistent.
I think my opengl-update patch in bug #78475 will resolve this issue.
I believe that the opengl-update patch in bug #78475 will hopefully work as it changes /etc/ld.so.conf to look in /usr/<libdir>/opengl/<implementaion>/lib . It still tries to create symlinks in /usr/<libdir>, but you can probably ignore those errors and it will still work.
I would prefer that it no longer give any errors, as an error would cause the operation to fail on a LiveCD.
Hey Chris, [ -w /usr/lib ] still returns true if /usr/lib is on a read-only filesystem. Do you know of a more elegant way to check that without doing some grepping in /proc/mounts as I'm sure you're more experienced with RO filesystems? Or is there an easy way to notice that we're on a livecd like [ -e /etc/livecd ] or something like that?
Chris, can you check comment #6 in bug #55212? Would that solution work for you? You could do 'opengl-update --prefix /etc/opengl-libs'?
There is nothing to identify the installation as a LiveCD. There is also no indicator that the filesystem is RO, as Linux itself thinks it is RW up until you try to write, which then fails pretty generically. I still think the best solution is to simply always use /etc/opengl, whether on a LiveCD or not.
While I agree that this stuff belongs in /etc as the best final solution, this problem impacts more packages than just opengl (gcc-config for instance with libgcc_s.so, etc). I will add --prefix and --dst-prefix options to the next release, and perhaps a discussion on -dev would be relevant to determine the layout of this stuff in /etc... then the result of that discussion can get into the following opengl-update. I'm for /etc/alternatives/{include,lib{,32,64}} as that seems to be what Mandrake is calling it... might as well use the same...
Well, we have a working opengl-update-livecd for the LiveCD in livecd-tools. so the original problem has been resolved. It works quite well, along with openglify to setup the opengl environment on the LiveCD. You can find the latest versions in CVS at gentoo/src/livecd-tools. It currently does not work on amd64 with multilib, as I have not had time to make it that robust.
Created attachment 50715 [details] openglify for opengl-update-2.1_pre7 This openglify should work with opengl-update-2.1_pre7 and multilib (note that I haven't tested it).
marking fixed as 2.1_pre7 has support for --dst-prefix.
