Re: 64-bit

Hi Isak,

On Monday 26 November 2007 11:44 pm, Isak Savo wrote:
> 2007/11/27, Justin Karneges <[email protected]>:
> > 1) Is it possible to make a 64-bit-only version of a .package?  Then we
> > could offer two package files, and users would just need to pick the
> > right one. The IRC log seemed to hint that this may be possible by
> > bundling the autopackage files (this seems to be needed anyway to avoid
> > the 404 error during install).
>
> We've always wanted to support 64bit systems, but just never had the
> energy to do it (or other more important things was fixed instead)
>
> Right now, you'd definitely need to bundle the runtime files, since we
> don't have a 64-bit version of it on our web. Part of the runtime is
> compiled c-code, so you'd need to compile it on a 64bit system.

Can you describe how to do this?  It sounds like it is probably not the same 
as traditionally bundling the autopackage files.  I presume this also means 
the package becomes 64-bit-only?  (which is fine, that's what I was asking 
for.)  Can my application remain 32-bit even if it is wrapped in a 
64-bit-only autopackage?

> > 2) Is it possible to make a 32-bit package that works on both 32-bit or
> > 64-bit platforms, with very minimal user instructions?  Something like
> > "install the 32bit compat libs, then run our 32-bit application package"
> > would be nice.  I saw this idea mentioned during my searches, but it
> > wasn't stated confidently (I get the impression that none of the AP devs
> > have 64-bit systems...).
>
> In theory, this is exactly how it's supposed to work. Problem is, from
> what I understand the user needs to have 32bit compatibility libs for
> ALL the app's dependencies. Many distros provide a bunch of base stuff
> (including X11, GTK etc.) as 32bit compat libs, but more exotic
> libraries might be missing.

I should be able to provide my own 32-bit packages for the "exotic" libraries 
in our application package file (or via URLs to our company website) 
shouldn't I?  It seems to me like compat libs shouldn't be a problem unless a 
distro is missing 32-bit compat libs on base libraries.

> One issue with this is our detection system. It is very hard to
> programatically determine if the users system is 32bit compatible or
> not (it'd require that all our dependency checking API functions
> became aware of this, not to mention all distros put the 32bit libs in
> different locations.)

Hmm, it sounds like the 32-bit compat approach is not very reliable then.  Two 
questions about this:

1) Is it possible to make 32-bit compat reliable?

2) Ultimately, do we really need 32-bit compat?  If we can get a dual package 
that contains both 32-bit and 64-bit binaries, then you'd never use compat.

> A good middle step I think would be to allow 64bit only packages to work.

And what is left for this to work?  Compile the autopackage runtime as 64-bit?

What is left to support autopackages containing both 32-bit and 64-bit?

> We fix minor bugs here and there, and for most people Autopackage
> works quite well. But none of us has the time or energy to do big
> changes.
>
> BUT. There's always a but. If you are willing to invest some time in
> looking into making autopackage more 64bit friendly I will certainly
> assist you in doing that. Maybe Taj and Curtis can help too.

Great, then here I am. :)

-Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]