On Sat, 2004-05-29 at 16:41 -0700, Bryce Harrington wrote:
No, it always goes back to the console at least a couple of times for input from the user. It did this on my own system and Judith's (both SuSE desktops.) It also displayed GUI authentication windows at least once.
I guess we have a problem with the latest version of SuSE then. This definitely sounds incorrect.
Well, I mean it should also list that it installed/upgraded autopackage and any dependency libs (gtkmm, etc.), as well as listing the version numbers that were installed. Yes you're right that it displayed that installation completion screen in most cases.
Yep, OK. We'd like to do this.
Ah, makes total sense now. Small world. Tell Jeremy hi. ;-)
Done ;)
Fwiw, this particular question arises from a concern being voiced by some of the OSDL member companies about "difficulty porting to / installing on Linux". They haven't been very specific so I don't know for certain if Autopackage would suit the needs, but I am thinking it may be worth presenting it to them this summer.
Knowledge of Linux installation/binary portability techniques is somewhat lacking. As we've been writing autopackage we've been documenting the various issues in our packager guide.
Yup, and admittedly veering completely off-topic for this list. ;-) We can move this discussion over to the autopackage-dev list if you'd like to continue the discussion, but you've answered all the questions I had.
I think we're almost done for now ... it seems we have issues on SuSE which I will definitely look into (this would not be the first time we have odd problems with various distros).
The one major dependency that has been identified that ISV's run into is libc. That's a tough one to get sorted out (and not one you'd want to automatically install for people...) But I'm thinking if Autopackage could download the correct version of the software to match the system libc, that may provide a cleaner solution than currently available.
Actually libc isn't much of a problem if you use apbuild - all autopackages are built with this tool: the inkscape package should not suffer any libc problems on any system > deb stable/RH 6.2.
glibc actually does a pretty good job of not breaking backwards compatibility. The main issue is that people don't realise you can control which symbol versions are selected by the linker using GAS pseudo-ops. One of the things apbuild does is modify the build system and inject assembly control sequences into the code as it's compiled to ensure you end up with a binary that can run on older systems.
The other issue people run into is stuff like thread-local locales (the missing __ctype_b_loc symbol problem) and libgcc exception frame handling (__register_frame_info_bases). apbuild also fixes these automatically.
Using apbuild btw is straightforward and does not depend on autopackage. Just "CC=apgcc CXX=apg++ ./configure"
Right. There are a few different approaches to this goal in addition to making the packaging software ultra robust, or including all dependencies in the core, some of which are being tossed around at OSDL.
Are you involved with OSDL? I didn't realise they were looking at this issue, if these companies have any questions they should feel free to talk to us. Between Wine/CrossOver (which is binary portable to any distro) and autopackage I've become fairly adept at dealing with binary portability problems.
Although, also consider that we can expect that as Linux continues to penetrate into the enterprise desktop market, there's going to be more instances of internal app development/rollout, where they'd want installation to be user-pull rather than IT-dept-push. In this use case I can imagine the app being built on open source components and the installer needing to be at least modestly dependency-aware.
Yeah. We have a few bits of code in there which currently aren't used, but are there to support corporate deployment scenarios when we support that in future. For instance the current plan is to be able to generate a basic (low quality) RPM from a given autopackage. Such a thing would perhaps not deal with dependencies like a native RPM would but it could be mass deployed to desktops using things like Red Carpet, apt/yum etc.
We'd also need to document exactly what autopackage itself depends on. Right now we haven't done this. Anything that may break in future or may not be present, needs to be included statically some how.
Yup, does libtool indicate this? In any case, it might be worthwhile in general to list distro/versions that autopackage has been tested on and will run directly.
Being written mostly in bash autopackage doesn't use libtool - actually one of the things apbuild silently fixes is the fact that libtool gets DSO dependencies wrong (at least on Linux).
Mmm, that may work for them. A possible enhancement for this would be a script to cache the dep's at the vendor's site, so that if the mirrors were bogged down or something, the user could still obtain them from the vendor's site. Again, certainly something the ISV could easily do themselves.
That's a pretty good idea, thanks. We have some support for mirroring, but I don't think there's any way to order them currently. I'll stick it on the TODO list.
thanks -mike