Getting started...
AndrewLuecke
We are thinking about branching Songbird into a community edition, and
instead of using a .tar.gz, we would like to investigate using
autopackage instead. Unfortunately, the tutorials and such are down at
the moment, so decided I'd post here before probing around..
Whilst we have a massive design document (
http://docs.google.com/Doc?docid=0AcU_F4NVncBXZGc0MmNkY3FfMjhmaGtyNm40ZA&hl=en
), I'd like the main ideas to see if they are easily possible with
Autopackage:
1) There are 3 options we are thinking about:
* An option to install System-Wide
* An option to install for a single user (to any location)
* A third which is the same as Single user, however, we need to run
some scripts after installation to set up the settings (basically, to
set up a portable copy on memory stick)
2) Customise Installed components.
* The software is broken up into components, and we'd like users to
select which components they wish to add. Some components (some just a
shell script of commands run during installation-only).
3) Show billboards/slideshow during installation
4) Maybe ask users some questions during the installation that affects
the way the installer works.
5) Download and run a special program during installation to show
users what will change when they upgrade.
6) Upgrade software.
I understand some of this stuff (like 5) will need to have a special
program coded (we can do that). But just wondering if its currently
possible
Eugene Zolenko
> * An option to install System-Wide
> * An option to install for a single user (to any location)
> * A third which is the same as Single user, however, we need to run
> some scripts after installation to set up the settings (basically, to
> set up a portable copy on memory stick)
This is all is possible with standard means.
> 2) Customise Installed components.
> * The software is broken up into components, and we'd like users to
> select which components they wish to add. Some components (some just a
> shell script of commands run during installation-only).
That will require writing your own frontend or a helper UI app that is
launched within install script. In default frontend there is no user
interaction (besides entering root password for system wide installs
and optional license agreement).
I went with second option and just made an app that is launched at the
start of install script and takes user input and creates a file that
controls the rest of the installation.
Implementing full custom frontend will give you much more integrated
look though :). There are Gtk and Qt frontends for autopackage so you
have 2 examples if you decide to go this route. I think all it does is
take progress messages from autopackage through named pipes and
display them to the user.
> 3) Show billboards/slideshow during installation
Same as 2
> 4) Maybe ask users some questions during the installation that affects
> the way the installer works.
Same as 2
> 5) Download and run a special program during installation to show
> users what will change when they upgrade.
Either part of 2 or just part of install script.
> 6) Upgrade software.
Upgrade consist of uninstalling old package and installing new one.
There is no patching as far as I know. If you break down you packages
carefully and have sane interface versioning you can limit number of
things to reinstall. You can also place all dependency packages online
and have autopackage download them when needed. This will limit
download sizes during upgrades.
Jan Niklas Hasse
>> 1) There are 3 options we are thinking about:
>> * An option to install System-Wide
>> * An option to install for a single user (to any location)
>> * A third which is the same as Single user, however, we need to run
>> some scripts after installation to set up the settings (basically, to
>> set up a portable copy on memory stick)
>
> This is all is possible with standard means.
I think the third option should be a standard Autopackage option. So
that any package just would have to set a flag like
Portable Yes
and then Autopackage automatically offers the third option before installing.
>> 3) Show billboards/slideshow during installation
>
> Same as 2
IMHO an installation should be fast enough that stuff like that isn't
needed. Also remember that the one installing the software isn't the
only one using it in the end. So I would rather implement this as a
Welcome screen on the first application start.
>> 6) Upgrade software.
>
> Upgrade consist of uninstalling old package and installing new one.
> There is no patching as far as I know. If you break down you packages
> carefully and have sane interface versioning you can limit number of
> things to reinstall. You can also place all dependency packages online
> and have autopackage download them when needed. This will limit
> download sizes during upgrades.
Creating real update packages which only contain patches was always
something I wanted to do, but never started due to lack of time. Man I
really need to hack on autopackage again ...
Eugene Zolenko
> >> * An option to install System-Wide
> >> * An option to install for a single user (to any location)
> >> * A third which is the same as Single user, however, we need to run
> >> some scripts after installation to set up the settings (basically, to
> >> set up a portable copy on memory stick)
>
> > This is all is possible with standard means.
Actually I should correct that -- there is no way to ask user, so
portable copy would be separate package.
> I think the third option should be a standard Autopackage option. So
> that any package just would have to set a flag like
>
> Portable Yes
>
> and then Autopackage automatically offers the third option before installing.
I don't think there is meaningful definition of being portable common
enough to be part of generic install. Even if there is, it won't be
exclusive with system-wide/local. Ability to give users some choice/
ask questions as part of standard UI might be good. But that goes into
UI scripting realm already.
Best way is always to put all the questions into apps themselves on
first run of course, but that isn't always possible...