Re: 64-bit

2007/11/27, Justin Karneges <[email protected]>:
> Hello all,
>
> We use Autopackage at Barracuda Networks for distributing our IM Client for
> Linux.  Recently we ran into a problem where users on 64-bit Linux platforms
> are unable to complete the install process.  I'd have probably written this
> off as a minor detail, since Linux is a fringe platform in the first place,
> and surely 64-bit Linux is even more fringe --- except that it turns out we
> have an entire internal department using 64-bit Linux.  This ended up being a
> very embarrassing situation when it came time to deploy our own software.

Ouch, sorry about that. Autopackage is also very bad at telling the
user it won't work on 64bit systems - ususally you just get a 404 from
wget or some other crappy error :-(

> I did some googling, as well as checked out the autopackage mailing list
> archives, forum, and IRC logs to get myself up to speed.  From what I gather,
> there has not been much consideration for 64-bit Linux.  Since autopackage
> appears to be the best tool for the job of installing third-party Linux apps,
> I'm willing to assist with making it work.  I'm really hoping I don't have to
> fallback to making rpms/debs for the 64-bit platforms.
>
> Questions:
>
> 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.

> 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.

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.)

But, if the compat libs are there, it's possible to launch a 32bit
program on an otherwise 64bit system without problems.

(And you're right, we (AP-devs) run 32bit machines. I do have a 64bit
laptop, but it's running windows most of the time and is not used by
me)

> 3) Is there a long-term goal to allow a single package to provide both 32-bit
> and 64-bit versions?  This would be the most ideal, giving an effect similar
> to Mac "universal" binaries.

This has definitely been a goal, since it would make it easiest for
the end user. I'm not sure we'll ever get there due to our limited
manpower and the technical challenges it involves.

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

> 4) Is Autopackage dead?  (maybe stupid question, but I was reading some
> Linux.com article about how autopackage doesn't get worked on, and that
> worries me).  If I must go somewhere else for my solution, I hope you'll be
> honest and tell me that's what I should do.  That said, if it is simply a
> matter of autopackage being incomplete (e.g. it is the right way if only it
> were actually written), then I may be able to help complete it.

It's definitely a valid question. I'd say it's not dead, but rather in
a hibernated, low-maintainance state  :-)

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.

If you decide the effort is not worth it, the closest alternatives to
Autopackage would be ZeroInstall (really interesting system
http://0install.net/). There's also Klik, but if I understand it
correctly, it's just a converter from rpm/deb to its own app-folder
style deployment model (which may be fine for you, don't know).

-Isak

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