Ticket #45 (closed Defect: fixed)

Opened 1 year ago

Last modified 2 months ago

Should warn that users that 64-bit systems don't work

Reported by: taj Assigned to: isak
Priority: Medium Milestone:
Component: main Version: 1.2.4
Severity: Normal Keywords: 64bit, stub
Cc:

Description

When attempting to install an Autopackage on a 64-bit system, Autopackage should tell the user that "64 bits don't work!" instead of dieing spectacularly (like in #42).

Just a quick test in the stub to make sure we're on 32-bit x86 should be good enough.

Attachments

64bit-detection.diff (4.4 kB) - added by taj on 12/29/07 11:54:57.
64-bit Detection and Warning
lib64.patch (2.1 kB) - added by Jan-Nik on 04/02/08 16:03:21.
checks if /usr/lib64 exists; let user continue installation if arch check fails.

Change History

12/29/07 11:54:57 changed by taj

  • attachment 64bit-detection.diff added.

64-bit Detection and Warning

12/29/07 16:29:17 changed by isak

Patch reviewed and tested on an AMD64 system running Ubuntu 7.04 - worked fine. (Warning received in both X and console, depending on how I ran the package)

12/29/07 16:46:06 changed by taj

  • status changed from new to closed.
  • resolution set to fixed.

Committed in r2425.

12/29/07 16:47:21 changed by isak

  • keywords changed from 64-bit, stub to 64bit, stub.

04/02/08 15:36:12 changed by Jan-Nik

  • status changed from closed to reopened.
  • resolution deleted.

I'm currently on openSUSE 10.3 x86_64 and getting this error although I have compatibility libraries installed (inside /usr/lib), because "uname -m" still returns "x86_64".

I think the error should be changed to a warning. With only a warning, users could still run these packages if they have a special case machine in which x86 does work. (for example if "uname -m" returns "athlon", isn't that x86, too?)

04/02/08 16:03:21 changed by Jan-Nik

  • attachment lib64.patch added.

checks if /usr/lib64 exists; let user continue installation if arch check fails.

(follow-up: ↓ 6 ) 04/15/08 11:53:29 changed by isak

  • status changed from reopened to new.
  • owner changed from taj to isak.

Hmm, this patch will cause problems for people on 64bit system which does not have 32bit compat libs installed. They should not be allowed to install 32bit packages at all.

The proper fix would be to detect 32bit libraries regardless of where they are. Can we do that somehow (without breaking the API)?

(in reply to: ↑ 5 ) 04/15/08 12:16:15 changed by Jan-Nik

Replying to isak:

Hmm, this patch will cause problems for people on 64bit system which does not have 32bit compat libs installed. They should not be allowed to install 32bit packages at all.

That's right, but I think the code for doing this should be moved to the support code, not in the package header.

I already managed to build the support code on x86_64 btw and it works flawlessly. If this build would be uploaded after someone created a package with 1.2.5, the 1.2.5 package won't allow you to download and install the autopackage support code (because the warning is inside the package file), although it's now online.

The proper fix would be to detect 32bit libraries regardless of where they are. Can we do that somehow (without breaking the API)?

Yes, I think that's possible. But as I said, it might be the best to let the support code do that. I looked inside the testForLib function and i saw that it already tests for 32bit libs only.

IMHO it would be best to remove the detection/error for 64bit system completely and build 1.2.5 on x86_64. This way 64 bit users won't be able to install 32 bit packages without the compatibility libs, too: The dependency detection (testForLib, ...) will tell them which libraries are missing.

(hope you understand what I'm trying to say)

04/15/08 12:37:01 changed by isak

Yes, it should be handled by the support code. The problem is that we cannot add new functions to the support code which is called from package stubs since it'll break on systems with autopackage < 1.2.5 (This is what caused the _checkEULA problems).

I'm not sure how to solve this in the least painful way.

08/03/08 13:15:25 changed by Jan-Nik

  • status changed from new to closed.
  • resolution set to fixed.

I close this for now as the next release will have 64 bit support, so a warning won't be needed any more.