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).
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).
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 ....
So I guess what was missing was a bit more feedback. Maybe a dialog that pops up and says, "Inkscape has been successfully upgraded from version X to version Y."
Yes, it'd be nice to have this in the summary screen.
It'd be extremely cool if it could also list "What's changed", although I'm not sure how that info could be easily pulled in...
It could just be metadata in the specfile.
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?
Do you have a hook for displaying the license? For some apps this will be considered pretty critical...
It's half complete. I doubt it'll be ready for 1.0, we're in feature slush right now. It's only necessary for proprietary software really, and currently autopackage does not provide good enough robustness guarantees for proprietary ISVs on Linux anyway.
I'm sure this is already on your todo list, but a GUI-based Uninstallation mechanism would be *very* nice.
Yep, it is definitely on the todo list. The main issue we need to work out here is simply how the user launches it. Currently neither Gnome (nor KDE i think) support the .desktop file Actions key. There is a patch for Gnome written by a friend of mine, but it's yet to be applied :(
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.
The main problem is that:
(a) for Gnome at least, that ability is at minimum 6 months away, assuming the patch is applied by Mark McCoughlin soon.
(b) Usability is not great. Right clicking on a menu item in the applications menu? That isn't very intuitive and doesn't work for any other type of menu.
Long term we may want to move to a garbage collection model for this sort of thing, but more R&D is needed. For now we may simply install an "Remove/Upgrade 3rd party software" item or menu.
Extra slick would be if it could detect when the user deletes the application entry from their desktop menu and prompt if they want to just remove the icon link, or uninstall the program entirely (in which case the icon only is removed if the uninstall was successful).
I've considered this. My experience with Windows indicates that a lot of people don't really understand the distinction between a link to the app and the app itself though.
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.
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.
There are a few different issues here. I'll assume we're talking about proprietary software.
(1) 3rd party software tends not to have many "non core" dependencies. If any libraries are used which the user may not have, they are often statically linked. That's undesirable but understandable, we have enough problems with random distro brokenness to worry about user not having libfoobar.so.2.3.1
(2) If the user cannot install the software, you get no sale. So, the installation MUST be 100% robust and reliable. Loki Setup is popular because it works, and is a simple known quantity. It doesn't do dependency resolution but that's OK, if your software depends on packages not in the base set of most distros you are already going out of business ....
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.
Proprietary software tends to be large, so we don't worry too much about installer overhead there.
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.
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.
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.
For the foreseeable future however dependencies will not always be available in such a form. In this case, either statically linking them or packaging it themselves is the way forward. I would recommend static linking actually as if you package it yourself, this violates the principle that maintainers should build their own binary packages as well as possibily causing conflicts in future if/when they do.
thanks -mike