Ruarí's thoughts

Summary of the changes

The work in these packages is not limited to just to removing a few Qt references. Our packages have been completely rewritten from scratch so that they do more things sensibly. For example the .rpm and .deb packages have cleaner post-install and pre-uninstall scripts and the tarball install script is entirely replaced. Additionally, the start-up sequence has been greatly simplified (take a quick look the 'opera' startup script in a text editor and compare it with an earlier build).

Most users won't notice major changes, a few will likely appreciate the improvements and the resolution of long time outstanding issues, and a minority might get tripped up by one of two of the changes. In an attempt to keep the numbers of the latter down to a bare minimum, this posting highlights some of the changes that might lead to confusion.

For a full list of changes, see the UNIX packaging section of the Changelog for UNIX snapshot 10.51-6252.

Nothing showing up in the applications/software menu?

Just a few quick points here. On some people's systems after install via the install script included with the tarball package Opera may not immediately show up your applications/software menu. If you find this to be the case the easiest quick fix is to logout of your account and then log back in again.

If you use KDE 3 and install via the tarball install script you will find that this still does not resolve the issue. The reason being that KDE 3 does not support having XDG files (icons and *.desktop files) being placed in '/usr/local/share' (more on this later). However, outside of Desktop Environment integration, Opera will be fully functional in all other respects.

Finally, if you use Debian or a derivative distro such as Ubuntu this may also happen with certain Window Managers because we no longer create a Debian menu file. For those unaware what this means, the Debian menu system was a basically neat hack for the fact that WMs each configured their menus differently. These days there is a standard way to configure and maintain applications menus. It is the fd.o menu system. As such many WMs have started to migrate to supporting it, thus slowly rending the Debian work around less relevant.

I obviously don't want to talk at length here about how to natively configure the menus of the multitudes of different WMs available on *nix but if you think this issue affects you and you want to manually get back what you had before, you can quickly create your own Debian menu file and place it in a suitable location, .e.g. make a file called "/etc/menu/opera" (or "~/.menu/opera" if you just want an entry for your current user), with the following contents:

?package(opera):needs="x11" section="Applications/Network/Web Browsing" \
  title="Opera" command="/usr/bin/opera" hints="Web browsers" \
  icon="/usr/share/icons/hicolor/32x32/apps/opera-browser.xpm"

Afterwards run the command 'update-menus' (you may also have to restart your window manager).

If you are curious as to why we are not providing a Debian menu file I would point out that first and foremost we wanted to support the fd.o[/url] menu system as it works on many WMs and DEs (Desktop Environments) and is cross distro. However we will be looking into supporting the Debian menu system in the future as well, once we have ironed out a few potential issues.

Opera and GTK

As has been said previously Opera is not based on GTK, nor does not depend on the presence of GTK libraries. That said, Opera will look like a GTK native application if the GTK libraries are available. Once support is added, the same will go for Qt (i.e. Opera 10.50 no longer depends on Qt but will be able to use the Qt to present itself with a native look if the libraries are available). However, our new .deb and .rpm packages may give some users the false impression of dependency. Why? In a nutshell, Opera now depends on GStreamer for video support, which on most distros cause GTK to be pulled in as well.

The issue actually lies with bad packaging for the gst-plugins-good package (also called: gstreamer-plugins-good, gstreamer-0_10-plugins-good, gstreamer0.10-plugins-good, gst-plugins-good-0.10, etc. depending on your distro of choice). Only a sub-selection of the files within this pacakage actually need GTK libs. Some distros have rectified the situation by splitting it into two packages, one needs GTK the other doesn't. We only need some of the GTK independent files. More detail can be found in this Debian packaging bug report.

If you have GTK applications installed already, are not overly concerned with some extra GTK libs being installed or have a distro that splits up the gst-plugins-good package you will not see any problem. However if you are on an distro that does not split up this package and you have religiously avoided GTK based applications, then attempting to install Opera via either the new .rpm or .deb package will cause your package manager to try and install various GTK libraries as a result of cascading dependencies.

So what should you do if you are a user who does not want any GTK libs on their system and your distro does not split gst-plugins-good into non-GTK and GTK dependant parts? Firstly I would encourage you to contact your distro and politely ask them to consider making their GStreamer packages more modular. This benefits not just Opera but other applications that make use of GStreamer libs but do not require GTK libs themselves. That said, these are your two current options:

• If you don't need video support right away (since it is not yet widely available on the web) you can install the Opera via the install script included with the tarball package. It will not check for dependencies and hence not complain about the lack of GStreamer. Other dependencies are unlikely to be an issue on modern Linux distributions. If you are on an RPM or APT (.deb) based distro you can switch back in the future by using the 'uninstall-opera' command (set-up by the tarball installer script) and then reinstall via a native package.
• Accept the GTK libraries for now and reconsider the situation at a latter stage.

Note: Yes, there are messier hacks to get Opera working with video and without GTK support on all distros but we would not recommend you go down this route.

If you are affected by this issue please give feedback below. We would be particularly interested in knowing your distro and if you have given feedback to the distro (and if so if there is an open bug report for the issue).

Supported installation directories

Opera now has three standard install locations: '/usr', '/usr/local' & '~/.local'. '/usr' is the install location when installing a native package type (i.e. an .rpm or .deb package). When installing one of the tarball packages via the install script, installation is to either the system as '/usr/local' or a user install in '~/.local'.

These install locations represent standardised locations for software install. Hence when software is installed to one of these locations it will have application menu entries and MIME types set-up correctly in the default configuration of modern Desktop Environments such as KDE 4, Gnome 2, Xfce 4, etc.

Long time users will note that the previously bundled install script ('install.sh') was less strict and allowed for installation to any location the user wanted, via the 'prefix' and 'DESTDIR' options. 'prefix'/'DESTDIR' was primarily used in the past for:

• Multiple installations: e.g. installing several builds, each to a different directory.
• Easy uninstall: installing to a non standard path made it easy to find and delete all Opera install files, should you need to uninstall later.
• Repackaging: Some users of non RPM or APT (.deb) based distros used these options to temporarily 'install' to a non-standard location, prior to repackaging files into a native package format (that can then be installed via the native package manager).

As only three install locations are now fully supported, it may initially seem that removing 'prefix'/'DESTDIR' is a serious inconvenience. However, that is not necessarily true.

Multiple side by side installs are now supported by the new install script, via install suffixes. During install a (user selected) suffix can be appended to the name of the install files and directories, e.g. if I was to use the suffix 'snapshot' the Opera startup script would become '/usr/local/bin/opera-snapshot' (for a system install) and the shared resource directory would become /usr/local/share/opera-snapshot (other files and directories will also be renamed in a similar vein). Better yet this suffixed install would get its own shortcut in the desktop environment's application menu and would use '~/.opera-snapshot' for its profile settings rather than the main profile ('~/.opera').

Uninstalling Opera is now made easier due to the fact that an uninstall script is created during installation (by the tarball install script) and placed in '/usr/local/bin' (or '~/.local/bin' for a user install). The uninstall script is called 'uninstall-opera'. If side by side suffix installs are done, a unique uninstall script is created for each, e.g. 'uninstall-opera-snapshot'.

Note: The .rpm and .deb packages do not set-up an 'uninstall-opera' script and should be uninstalled by the native package management system.

Installation to alternative locations and re-packaging Opera

If you have previously installed Opera to alternative locations and are concerned by the lack 'prefix'/'DESTDIR' options, firstly consider why you did this in the past and if you really still need this functionality. We would appreciate your feedback if we have missed other benefits of prefixed installs. Whilst some users will find it relatively easy to patch the install script to allow for installation to alternative locations, giving a clear explanation of why you need this option will likely benefit other users, since we are not adverse to making further improvements to the install script where a strong case is demonstrated.

Repackaging Opera is a good example of where alternative install locations could be needed and indeed it is something we are already very aware of. With fixed install locations our new script is not well suited to repackaging, however we do have some plans in the pipeline to assist distro maintainers and users who want to repackage Opera. For now we would advise users of non RPM or APT (.deb) distros to use the install script directly, whilst you await these improvements.

Note: If you can't wait for the proposed repackaging improvements then it is probably easiest to use the .deb or .rpm packages (rather than the tarballs) as a base for repackaging. If you use the .deb, 'ar' or libarchive utilities (e.g. 'bsdcpio' and 'bsdtar') can pull apart the package and you can then extract the contents of the internally contained 'data.tar.gz', excluding the Debian specific 'usr/share/lintian' directory and 'usr/share/doc/opera/changelog.Debian.gz' file. Alternatively the .rpm file can be opened with tools such 'rpm2cpio' or libarchive. Files extracted from either package are already set-up in the correct layout for install into the top level of '/usr'.

Edit: For example, assuming the use of '/tmp/repack' as your repackaging working directory, download a .deb appropriate for your hardware architecture and issue the following:

$ ar p opera_10.51-6252_i386.deb data.tar.gz | tar xz --exclude changelog.Debian.gz --exclude lintian -C /tmp/repack

This will create a 'usr/' directory under '/tmp/repack' with everything already in its correct location. You can then delete the opera_10.51-6252_i386.deb file.

Note: 'ar' is included as part of the GNU Binutils package, so it can be pretty much guaranteed to be present on any system that is used for repackaging.

As a further example for Archlinux users, here is a sample Arch PKGBUILD using the .rpm packages as a base. You'll again note how simple this script is.

Ok, questions??