Jannis Pohlmann info at
Mon Aug 15 14:28:09 CEST 2005

Benedikt Meurer schrieb:
> 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
> installer:
> 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.
> Benedikt
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at

That pretty much sounds like what we had in mind, too. We forgot the
mirroring concept but that's a good (and quit important) idea. I like it.

Of course there would be no restriction to goodies. Having said this,
the manager shouldn't be based on Xfce libraries - otherwise installing
installing Xfce using the manager would require Xfce to be already
installed. We thought about writing it in C and GTK+ (of course) so that
should be no problem.

Debugging support is fine for me.

"package list" != "description file"? - I just want to be sure I didn't
misunderstand what you meant. The package list includes all packages
available (with name, URLs etc.), while the descriptions file includes
goodie-specific information (build options etc.), right?

- Jannis

More information about the Xfce4-dev mailing list