Author
Topic: VL64 x86 Repositories/Slapt (Read 12221 times)

I'm new, so I will ask the stupid question (and my searching through these forums hasn't already turned up an answer, I promise I tried to look first):

Is there now or is there planned-for a simplified (for the user) x86 alternate repository for the VL64 series? The best solution to my problem (I want to run mostly x86 programs, but my box has 8GB of RAM and I am loathe to switch to the x86 version and lose half my investment) I have found so far is this.

What my wild, clueless imagination keeps wanting to make real is some sort of option to set up the x86 libraries and compiler suite to some mount point (\x86bin or something) and then a way to point slapt-get to the x86 repository and the \x86bin and to never interfere with the x64 stuff.

If this is even remotely possible, I am beyond willing to work on this problem with anyone more knowledgeable than me and to dedicate my contribution efforts towards this. It would certainly (I think?) be valuable and useful for the VL64 line.

I stumbled across this problem because I am lazy and would rather work really hard to figure something out and make it work and then do minimal work to maintain it after.

If this is a stupid, clueless question, please let me know - and let me know what I can/should be doing instead.

Thanks!

V/R

-Langobard

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR

...In fact you may not 32 bit at all. Depends on what programs youneed.

Yup, this has been my assumption. I am going to need Wine for sure, I was gearing up to be lazy with (and learn to contribute to) PlayOnLinux for most of my holdover x86/Windows requirements. Now that you mention it though, aside from Wine/POL, I am trying to determine what else I might want and/or need. You've made me actually think about and revise my position - and look at the x64 repository a second time...

Conclusion: I do not need nearly as much x86 compatibility as I thought - in fact, outside of Wine/POL, I am looking at fewer than a handful of x86 programs for which I have probable (p>.5) use. This thread was useful for changing my position, but probably not of use to anyone else.

Thank you both for your time and responses.

Altered Position: I would like to contribute to VL64 packages/testing/etc.

Clarification Question: Is there a better way to institute multilib than this?

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR

VL is multilib ready.you can run any 32bit VL program by installing it and copying any libs it needs into /usr/lib/If you need to compile 32bit programs you will have to add the multilib compiler and glibc

uelsk8s: Thank you. I didn't know that (or misunderstood what I had read). So, for example, if I wanted to install PlayOnLinux (which, iirc, is available in the x86 repo for VL7.0), I would download/install it and everything else it needs to /usr/lib/ ? Or did I misunderstand again, and that will cause errors?

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR

Why not use a 32-bit lxc container inside your 64-bit OS ? should be able to do what you need there. I do it very often for other reasons of cou ese, but I think the principle of containers would be helpful here

Mostly because I am green enough not to have even known that was an option. But if my research (doing it now) follows my guess, then this is basically what I wanted in the first place - a relatively simple way to run 32-bit apps/etc within my x64 machine without dual booting or something similar. I am applying my google-fu to the information now, but it can't hurt to ask: Do you have any guides/walkthroughs/information for doing so?

Secondary Question: Would it be useful, do you folks think, to have such a documentation specifically for VL64? Did my original idea (altered to be within an lxc) contain any value? This is partially/potentially ignorance that makes me ask - I don't know enough yet to know if this is superfluous to users in general.

Tertiary Question: Is lxc worthwhile, for example, for running a game in WINE on VL64? Or are there limitations that would make this inefficient/inadvisable?

As always, thank you for your time and knowledge!

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR

I have done a lot of work on that front, but I tend to fail at documenting stuff. The good thing with lxc is that it is self-contained and will not mix the stuff from you 32 bit environment into your 64 bit. The other good news is that you create the environment with a couple of commands.

I don't know what version of vl you run, but you will definitely want 7.1 for this, because that's where I have done the work at and the process will be easier there because the platform is ready for it. You can grab the latest beta I so and install it.

Re: your 2nd question... Documentation is always good and welcome. I can show you how to do it and you can document it if you want. When you are done you can contribute your findings with us.

Re: your 3rd question: The biggest advantage to lxc is that you have next to no overhead at all for your virtualized environment. So, your games should run good once setup properly. Take that for what its worth. I have not done any gaming, so we would have to do the research and break the ground there, but I do think its a viable option, if not your best available for vl.

You are welcome to come by our irc channel and discuss this. I'm normally on from 8am to 4pm CST

uelsk8s: Thank you. I didn't know that (or misunderstood what I had read). So, for example, if I wanted to install PlayOnLinux (which, iirc, is available in the x86 repo for VL7.0), I would download/install it and everything else it needs to /usr/lib/ ? Or did I misunderstand again, and that will cause errors?

that is correct.just download and run your 32bit app.you will need to add any libs that it needs though.if you want to run the same app in 32 and 64bit you will need to explode the 32bit pkg and copy the binaries somewhere that they won't overwrite the others.

just download and run your 32bit app.you will need to add any libs that it needs though.if you want to run the same app in 32 and 64bit you will need to explode the 32bit pkg and copy the binaries somewhere that they won't overwrite the others.

Clarification: If I wanted to run Some32BitApp, I would download it from wherever and (assuming I had the right libs/etc), I could run it as normal without breaking anything (unless it shares a name with a 64-bit app)?

Secondary Question: That being the case, would it be possible/worthwhile to set up some list/repository of apps that do not have an x64 equivalent, but do exist in the 32bit repository for VL?

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR

Clarification: If I wanted to run Some32BitApp, I would download it from wherever and (assuming I had the right libs/etc), I could run it as normal without breaking anything (unless it shares a name with a 64-bit app)?

Yes.

Quote

Secondary Question: That being the case, would it be possible/worthwhile to set up some list/repository of apps that do not have an x64 equivalent, but do exist in the 32bit repository for VL?

Seems like a good project to start on (list first) then. I will do so over the next week or so, digging up what I can.

Clarification: Do the 32-bit apps rely on 32-bit dependencies (in the case where SomeApp requires UsefulApp >=1.4 to be installed, and UsefulApp has both a 32 bit and 64 bit version both named UsefulApp) or can they use the 64-bit dependencies, or is it case-contextual?

« Last Edit: January 12, 2014, 08:15:18 am by langobard »

Logged

“World domination is such an ugly phrase. I prefer to call it world optimisation.” - HPMOR