Benedikt Meurer benedikt.meurer at
Mon Aug 15 14:02:45 CEST 2005

Jannis Pohlmann wrote:
> Option B)
>   A "real" goodies manager for listing/downloading/installing goodies
>   from source.
>   Each goodie provides a file with compile options and information about
>   version, name etc. The goodie's source tarball, once it is released,
>   are transfered to a server which is accessable by the goodies manager.
>   Maybe there's a cronjob running on it, which writes the list of
>   available goodies into an XML file or something like that.
>   The goodies manager updates this file on startup and displays the
>   goodies (and determines which already are installed etc.). The user
>   selects which ones he'd like to install/uninstall. The goodies manager
>   downloads the information file and the goodies' source tarballs,
>   unpacks them and runs an installation wizard for each one. During
>   installation the installed/manipulated files are logged and stored
>   somewhere on the disk (used for uninstallation later).
>   --
>   That's the way we'd prefer. There'd be lots of advantages (goodies
>   remain as sources, downloads are smaller, there's much lower effort in
>   providing goodies to the goodies manager etc.)
> That's it. How do you think about that? I'd really appreciate more
> details about what you discussed with nestu.

Option B is what I had in mind, because - as I mentioned earlier - the
"single .bin file contains everything" attempt used to be somewhat
complicated to maintain and extend.

The idea was to have a master server (, which offers an XML
file that lists all available mirrors. On first run, the installer
connects to the master server and fetches the mirrors list, and presents
the user with a list of available mirrors.

Then - once the user selected a mirror - the installer connects to the
mirror and fetches the packages list (also an XML file) from the
selected mirror. The package list contains informations about all
available packages for this mirror. This includes the name of the
package, the location of the tarball, the location of additional
patches, etc. (pretty similar to the BSD ports system).

For example, you can check the description file for the gtk-xfce-engines

The description file would also contain additional information required
to register packages with local package management systems (pkg_add,
pkgadd and RPM are more or less trivial, DEB will be a bit tricky, but
also doable).

Then, if the user selects certain packages and hits 'Install', the
required files will be fetched and untarred/patched. Afterwards, a
wizard will popup which displays several options, that can be selected
at compile time (this will also be listed in the descriptions file). In
addition, there'll be a few generic options, like additional CFLAGS,
etc. but that should be hidden from the default UI.

And last but not least, the selected stuff will be compiled and
installed with the selected options.

All this should work in a portable manner and should be as generic as
possible (like the current installer). Supported platforms should
include atleast Solaris, *BSD and the most common Linux distributions.
That said, it won't be limited to "goodies", but you'll be able to
install every desktop app (well, maybe not every, but most) from it, as
long as a description is available, so we can completely replace the
current installers (Xfce, Terminal/libexo, xfce goodies and
gtk-xfce-engines) with the new system for Xfce 4.4.

> Regards,
> Jannis


More information about the Xfce4-dev mailing list