Some thoughts about Salix, Slack, etc. / Opera 11 SLKBUILD

[ruario]

Hi,

Firstly a quick introduction. My name is Ruarí and I work in testing/QA for the desktop division of Opera software, specifically working on Linux/FreeBSD. Generally I use Arch and Slackware as my primary OS on my main machines, however I use a handful of packages from the Salix repositories and I have had a play around with Salix in a VM. All in all it is very impressive, striking a nice balance between staying very close Slackware, whilst adding a few niceties. Anyway I have a blog where I give my thoughts on Linux, packaging and various other things that interest me. I also write about Opera tips and bug work arounds. It isn't particularly high profile, nor am I trying to suggest any of you subscribe (sometimes I am pretty boring! ) but I have written a couple of posts recently that might be relevant to someone here. Particularly if you use Opera.

Anyway, most recently I wrote some thoughts on Arch and Slackware, in which I also touch a little on Salix. Towards the end I also link to an Opera 11 SLKBUILD that I quickly knocked up, since I see that the one in your repository is for the previous version (10.63). Perhaps someone could make use of the it (it might need some cleanup though, as it is my first attempt).

Thoughts on Arch, Chakra, Slackware and Salix. Plus a couple of Slkbuilds

Also, my previous posting is about repackaging Opera more generally and includes some thoughts about Opera dependencies:

Repackaging Opera for Linux (or FreeBSD and variants)

Edit: I have added the links in now as I have posted a few time and hence am allowed.

[pwatk]

http://my.opera.com/ruario/blog/

Welcome to the forum.

[thenktor]

Firstly a quick introduction. My name is Ruarí and I work in testing/QA for the desktop division of Opera software, specifically working on Linux/FreeBSD. Generally I use Arch and Slackware as my primary OS on my main machines, however I use a handful of packages from the Salix repositories and I have had a play around with Salix in a VM. All in all it is very impressive, striking a nice balance between staying very close Slackware, whilst adding a few niceties.

Thanks

Anyway, most recently I wrote some thoughts on Arch and Slackware, in which I also touch a little on Salix.

Feel free to write more about Salix

Towards the end I also link to an Opera 11 SLKBUILD that I quickly knocked up, since I see that the one in your repository is for the previous version (10.63). Perhaps someone could make use of the it (it might need some cleanup though, as it is my first attempt).

As mentioned in private mail to you, Opera 11.0 was added to our salix-current repository. And of course it's nice, that you've worked on a SLKBUILD. If you are interested and if you are going to use Salix more often you could be the official maintainer for the Salix Opera package.

Edit: I see I can't post links yet as I am a new users to the forums.

Sorry, I had to introduce this behaviour because of the increasing number of spam postings

[thenktor]

I just post this here, because I don't know where I should do this elsewhere. JRD mentioned that the OPERA_PERSONALDIR is not freedesktop.org compliant. The original opera start script uses:

Code: Select all

export OPERA_PERSONALDIR="\$HOME/.opera"

I've changed this to:

Code: Select all

if [ -z "\$XDG_CONFIG_HOME" ]; then
	export OPERA_PERSONALDIR="\$HOME/.config/opera"
else
	export OPERA_PERSONALDIR="\$XDG_CONFIG_HOME/opera"
fi

to reflect the standard:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

[ruario]

Welcome to the forum.

Thanks

Feel free to write more about Salix

Perhaps I will. Its a very nice peice of work. I might install it next time instead of Slackware

As mentioned in private mail to you, Opera 11.0 was added to our salix-current repository.

I actually missed your email at first but i have just seen it and replied to you with some more thoughts

And of course it's nice, that you've worked on a SLKBUILD. If you are interested and if you are going to use Salix more often you could be the official maintainer for the Salix Opera package.

I have to be a little careful agreeing to such kind offers. People from other distros have made the same suggestion (indeed that is how I ended up maintaining the Arch PKGBUILD). If I agree to to many I might over commit myself. However on the other hand if you ever feel it is too much to maintain I would gladly take over rather than see Opera dropped from the distro.

I am actually working with a colleague at the moment to check the feasibility of adding other package formats to our officially supported set. Slack packages are an obvious option since quite a few distros are based on it. Hence this might be a better long term option. I'll post back here with an update if it looks like this could become a reality.

Sorry, I had to introduce this behaviour because of the increasing number of spam postings

No problem I can certainly understand that!

I just post this here, because I don't know where I should do this elsewhere. JRD mentioned that the OPERA_PERSONALDIR is not freedesktop.org compliant. The original opera start script uses:

Code: Select all

export OPERA_PERSONALDIR="\$HOME/.opera"

True and actually we know this. We are a bit of a victim of history here. We set it to $HOME/.opera when it was common for apps to save their profiles in home directories. If we change it now we have to deal with upgrade issues of moving long term users default profiles. A lot of users make use of alternative directories for their profiles either by setting this variable or via '-pd' so we have to be careful we don't cause and issues. If done incorrectly we risk having users seemingly lose their setup. In the long run we will probably do this (and have Opera's cache stored in '$HOME/.cache/opera') in the mean time we make do with not being totally compliant here. By all means set OPERA_PERSONALDIR to $HOME/.config/opera in the startup script /usr/bin/opera on the SLKBUILD, if you feel it need to be done for compliance with your distro but expect some users to be confused unless you can think of a good way of warning them of this change.

[ruario]

Just one more thought with regards to $XDG_CONFIG_HOME/opera. If you set it for the user they ever switch to another package Slackbuilds, official package, etc. for some reason (perhaps because the SLKBUILD was not updated) their profile in $XDG_CONFIG_HOME/opera won't be found. Hence I think it is safer to leave it as $HOME/.opera for now to avoid such issues and confusion. I'll see if I can put pressure on to get a fix this our side.

[ruario]

I have updated my Slkbuild examples/tests with more comments so it is clearer why I do things the way I do. I also wrote a more generic repacking script for converting any Opera tar package into Slackware (and hence Salix) native format.

I did this partially for myself as I (obviously) use a lot of internal Opera builds and think it is nice to have Opera natively integrated with other packages on my system. Though I figure it could be handy should anyone else want to use one of our development builds, since they would not have to manually update a Slkbuild all the time.

[ruario]

I have updated my example SLKBUILDs (opera and opera-devel) and have added a few things I recently changed in the Arch opera-devel PKGBUILD. I also switched to letting makepkg deal with the symlinks. I now see the point of this. It requires less maintenance and also the symlink creation shell script code has to be written a particular way for removepkg to realise that symlink creation happened. Hence unless you format it exactly as makepkg would have done then removepkg will leave behind symlinks on uninstall.

As it happens I do know how to format the symlink shell script code the way makepkg would have done (as I now do it correctly now for my op2slk package conversion script) but I guess it is better not to hack around the standard way that slkbuild does things. After all this is a tool to simplify things.

The reason that I tried before was that I find it annoying that skbuild doesn't seem to let you use the prepend shell script creation code (makepkg '-p' option). This is needed for several of icons to be recognised immediately after install because the other part of doinst.sh expects them to be present (i.e. the calls to update-mime-database, gtk-update-icon-cache, etc.). In some desktop environments (e.g. KDE) this probably won't be a problem as you don't really need to make those calls anyway but in others (e.g. Gnome) the icons will initially be missing until the user logs out and back in again.

Currently, you can of course run:

Code: Select all

slkbuid

followed immediately by

Code: Select all

sed 's:\(/sbin/makepkg\):\1 -p:' -i build-opera.sh

but it feels a bit hacky. So where can I report this slkbuild issue?

P.S. As a side note for any Opera users reading this, I wrote a small shell script that can be used to keep Opera up to date. It also has the nice feature that it can call op2slk and make Slackware native packages.

[gapan]

The reason that I tried before was that I find it annoying that skbuild doesn't seem to let you use the prepend shell script creation code (makepkg '-p' option). This is needed for several of icons to be recognised immediately after install because the other part of doinst.sh expects them to be present (i.e. the calls to update-mime-database, gtk-update-icon-cache, etc.). In some desktop environments (e.g. KDE) this probably won't be a problem as you don't really need to make those calls anyway but in others (e.g. Gnome) the icons will initially be missing until the user logs out and back in again.

I think this is a problem (bug?) with xfce only. I don't remember gnome having any such problems. KDE certainly doesn't and neither does LXDE. That's the reason there is that "Rebuild icon cache" tool under the system menu in xfce too.

In any case, maybe I'll make slkbuild use the -p option by default. I can't think of an harm in doing that.

[ruario]

I think this is a problem (bug?) with xfce only. I don't remember gnome having any such problems. KDE certainly doesn't and neither does LXDE. That's the reason there is that "Rebuild icon cache" tool under the system menu in xfce too.

When we last made a significant change to the official Opera packages (.rpm, .deb and cross distro tar) the initial testing was done in Gnome and KDE. The shared parts of the post install instructions were done for the benefit of Gnome, i.e. the following:

Code: Select all

# Setup menu entries
if command -v update-desktop-database >/dev/null 2>&1
then
        update-desktop-database -q usr/share/applications
fi

# Setup MIME associations
if command -v update-mime-database >/dev/null 2>&1
then
        mkdir -p usr/share/mime/packages
        update-mime-database usr/share/mime >/dev/null
fi

# Setup icons
touch -c usr/share/icons/hicolor
if command -v update-icon-caches >/dev/null 2>&1
then
        update-icon-caches -tq usr/share/icons/hicolor
elif command -v gtk-update-icon-cache >/dev/null 2>&1
then
        gtk-update-icon-cache -tq usr/share/icons/hicolor
fi

If memory serves KDE didn't really need any of this. I 'think' it just worked as soon as you placed the various files in the right locations (at least with recent KDE versions on the distros we tested). By the time we came to testing Xfce and others we already had these Gnome workarounds, so I can't really comment if Xfce or others needed them or not.

Things may have changed in Gnome since then and perhaps Xfce does display similar issues as you state. Either way I agree with you that the fact any of this needs to be done if is a bug and hence the post install is really just a work around for such bugs.

Of course without makepkg's '-p' the work around I am including in my Opera Slkbuild is effectively a waste of time. There might as well be no post install (other than symlink recreation). So you can see why I am keen to gain an easy way to access the '-p' option.

In any case, maybe I'll make slkbuild use the -p option by default. I can't think of an harm in doing that.

I generally tend to agree. I can't really imagine it can cause to much harm. All it effectively does is promote symlinks to the same status as that of other files within the package. By that I mean they are all present before the rest of the post install, just like all other files and directories. I would think this could only be a good thing, especially where the post install instructions have been taken or based on those from packages of other non-Slackware based distros (like the Opera Slkbuild I posted), since the original authors of those post install instructions would have assumed those files where already in place.

Nonetheless it might be nice if there was some way to configure or switch this option on and off, just in case it has unintended consequences. I would hate to think that other packages became broken just because of a request I made! Anyway since you appear to be the author of Slkbuild I'll assume you know what is best and will make the right choice. Thanks for at least considering my thoughts.

I would also like to say if you are the author of Slkbuild, thanks so much it. It is a fantastic solution. I think it was wise to model on Arch's PKGBUILD. Additionally I don't think you could have done it more elegantly. I mean you could have skipped the intermediate step of converting to a regular build script first and to some this may have seemed like a good idea but your way gives two clear advantages. Firstly the build script can be shared with those who do not have Slkbuild installed and secondly final tweaks like my "sed 's:\(/sbin/makepkg\):\1 -p:' -i build-opera.sh" are always possible, meaning none of the power of a manually created build script is lost! So I just wanted to say well done!! It also demonstrates to me that you Salix guys really know your stuff, something I had already begun to realise. I wonder if the next time I install 'Slackware' I might actually just install Salix. I honestly think I might!