On Sat, 29 May 2004, Mike Hearn wrote:
On Sat, 2004-05-29 at 14:15 -0700, Bryce Harrington wrote:
For the graphics-based installation it would probably be wise to minimize the amount of stuff occuring on the console. There's a couple places where the user has to type 'Y' or hit enter in a console window, that would be better implemented as buttons in a GUI dialog.
Hmm, there should only be one: when you are first prompted to install autopackage itself. Once you have hit enter or pressed Y here the rest should be entirely automatic (assuming you ran as root, if not then you should get a GUI authentication window).
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.
At a couple points it prompts 'Y/n' but just hitting 'enter' does not do the same as hitting 'Y', as one would expect. This needs to be fixed.
Yeah, that's a bug. Could you list the two points where you had to do console interaction? It should only be one, and after you have installed autopackage for the first time there shouldn't be any at all (ie it's all graphical).
I believe it was a) Autopackage-Gtk, and b) Autopackage.
While the upgrade process was very smooth and effective, it felt like something was missing. Perhaps this was because it occurred all on the console and I was expecting a GUI to pop up, or perhaps because it wasn't obvious that an upgrade had actually occurred (I had to launch Inkscape and try out a feature I new had just been changed in order to verify it).
When you say upgrade process, what exactly do you mean? Basically the only upgrade "support" currently present is that any existing package will be uninstalled before installing the new one when you run it. The installation of the new package should be entirely graphical, same as usual.
I suspect we still have X authentication issues here if you are seeing this much console interaction ....
Hmm, that could be. Ah well, I'm sure if so, others will be reporting the issues.
Probably during installation in general it'd be worth having a final screen that very clearly says, "The installation of Inkscape version X was a success." A summary of dependencies installed and maybe the release notes might be nice.
We already do? http://autopackage.org/screenshots/gtkfe/finished1.png
That screen lists all the packages that were installed along with menu entries that were put on the system. Are you sure you're seeing the sort of things on the http://autopackage.org/gallery.html page?
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.
Also, have you considered ways of providing hooks for tying Autopackage into the desktop stuff or the application itself? For instance, I'm thinking if a user could right-click on the program icon, or the application menu, and have options to "Upgrade"/"Uninstall"/"Reinstall"/"Package Info" etc. it could give a much better user-friendly package management solution than is available in *NIX or Windows currently.
Yes we want to do this, as I mentioned above some of the necessary patches have already been written.
Okay, cool, thanks.
We have a long term UI vision for autopackage, that has been discussed on the mailing list at various points. I'm going to write it up into a "vision document" soon, so hopefully our UI goals become clearer :) The eventual goal is a totally transparent system with an UI somewhat resembling the one on MacOS X.
Cool. That'd be a great document to read - definitely let me know when you've got it, I'd like to read it. Meanwhile I'll sub to the list.
Finally a more general question - say you're an ISV and want to provide an Autopackage version of your software for use on any Linux distro. How "hard" will this be for a company that doesn't know Autopackage? What considerations will they need to take into account? Would they need to identify/provide packages for sub-dependencies themselves? What documentation would you point such an ISV at?
When I'm not being a student/living/working on autopackage I am an engineer with CodeWeavers, Inc (we make CrossOver, a semi-proprietary version of Wine). So in effect I am also a 3rd party ISV.
Ah, makes total sense now. Small world. Tell Jeremy hi. ;-)
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.
There are a few different issues here. I'll assume we're talking about proprietary software.
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.
(1) 3rd party software tends not to have many "non core" dependencies.
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.
(2) If the user cannot install the software, you get no sale. So, the installation MUST be 100% robust and reliable.
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.
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.
Autopackage currently does a few things we'd need to fix to make it really attractive for companies. In particular we would need to allow bundling of the core code and gtkfe inside the package: currently we invoke the "Please wait while autopackage is downloaded and installed" process you saw earlier. Replacing this with a graphical version is on the todo list, but it's not an ultra-high priority right now. Anyway, any installer which requires an internet connection is right out for proprietary ISVs.
True, but not necessarily. But yes, good point, a CD-based installation mechanism would be a good addition.
One usage scenario that I think may become common in Linux desktop rollouts would involve network-based installation from within the company LAN. This would probably require some sort of server-side license-counting mechanism, but the ISV could certainly figure out how to set that up themselves.
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.
I have some plans for some distant point in the future to allow autopackage to make greater use of ELF binaries as generally the glibc/kernel interfaces are far more stable than interfaces to various shell script tools such as what we use. But that's a long way off.
That would be cool, but I too suspect it'd be a lower priority for ISV's, many of which rely on a shell script for installation. It seems pretty safe to assume any *nix system you're going to install on will have shell script capabilities.
As to would they have to package extra components themselves: this is the same as for open source software. In theory no - in the ideal world all library/component projects provide some binary package in some form that autopackage knows how to use, whether that be another .package or RPMs/DEBs/whatever.
Then they just have to publish a luau XML file on their web server, add the URL to the skeleton file and from that point on all packages compiled will be able to resolve them from the web.
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.
Thanks, Bryce