[proposal] The Opera browser

arkham · 2009-11-26 17:18:22

Hello, I have been maintaining opera-devel-qt4 for some time: it's nice to see that the Opera guys are considering our community!

Now, moving on to the new PKGBUILDs, I tend to dislike the automatic fetching of the latest package for a couple of reasons: first of all, it goes against the KISS principles. The PKGBUILD should remain easy to understand and modify: if my package is out-of-date, it is simply necessary to open the PKGBUILD, change the _build variable and update the md5sums to get the latest version. Anyone with enough knowledge can do that in virtually no time.
The second reason that makes me dislike the automatic process is the lack of testing: currently, my package is updated once a week and the version that is submitted to the AUR is tested by me beforehand, so that I can understand in advance which problems (if any) are brought by the latest update. If the script gets the latest version automatically, then such testing cannot be assured.

My point is that a PKGBUILD shouldn't do what a VCS should do. The PKGBUILD should remain small, simple and easy to use. Adding features like automatic update fetching makes it more clunky and un-KISS.

quarkup · 2009-11-26 17:51:03

Well I agree with you on the KISS principle.

IMO we need to first change and split the PKGBUILDS then we move on to remove those automatic updates

quarkup · 2009-11-30 18:40:34

now for the PKGBUILD scripts, please check my next post below.

opera-qt4 http://dpaste.com/127017/

(stripped)
pkgname="opera-qt4"
(stripped)
pkgver=LATEST
(stripped)
# parse the opera's ftp for the latest release's version (something like '10.10' or '10.01')
_pkgver="$(wget -q -O - 'ftp://ftp.opera.com/pub/opera/linux/' \
| grep '/pub/opera/linux/' \
| sed -e 's|.*<a.*\">||g' -e 's|/</a>||g' -e 's|^.*b.*||g' \
| sort -g | tail -n 1 \
| sed -e 's|^..|\0\.|g' -e 's|\ ||g')"
pkgver="${_pkgver}"
(stripped)

opera-snapshot-qt4 http://dpaste.com/127077/

(stripped)
pkgname="opera-snapshot-qt4"
pkgver=LATEST
(stripped)
# parse the opera's desktop team for the latest snapshot's build and version
_build="$(wget -U 'Opera/9.80 (X11; Linux i686; U; en-GB) Presto/2.2.15 Version/10.10' \
-q -O - 'http://my.opera.com/desktopteam/blog/' \
| grep 'snapshot.opera.com/unix' \
| head -n 1 \
| sed -e 's|.*/unix/||; s|/.*||')"
_pkgver="$(wget -U 'Opera/9.80 (X11; Linux i686; U; en-GB) Presto/2.2.15 Version/10.10' \
-q -O - "http://snapshot.opera.com/unix/${_build}/intel-linux/" \
| grep 'gcc4-qt4.i386.tar.gz' \
| sed -e 's|<img.*> <a href=".*">||g; s|opera-||g' \
-e "s|${_build/*-/-}.gcc4-qt4.i386.tar.gz</a>.*||g")"
pkgver="${_pkgver}.${_build/-/}"
(stripped)

@arkham
the maintainer should remove that pkgver code and put the version.
the variables to be changed are $_pkgver and $_build (only for the snapshot version)

for the 'opera-qt4' package, the $_pkgver variable should be something as simple as '10.10'

for the 'opera-snapshot-qt4' package the $_pkgver variable should be something as '10.20'
and the $_build variable should be something like 'snapshot-4744' or 'rc-4728'

Last edited by quarkup (2009-12-04 10:46:35)

ruario · 2009-12-03 09:41:57

I'm starting to see arkham's point about simplicity.

@quarkup: Don't get me wrong, your PKGBUILD is very clever but perhaps too clever. It probably assumes too much. Having looked at the new install script a little I can see that your method of always grabbing the latest version will fail as the new install script has totally different arguments. It could also break if we add certain new features or change our naming scheme even slightly.

I think therefore it would be better to go back to versions hard coded against to the current latest package. As such I have abandoned opera-g3.

quarkup · 2009-12-03 11:53:15

well I really do agree with arkham !

I prefer a simple script than a hardcoded one, its a matter of simplicity. The part of the script should be "removed" and instead the maintainer should change the _pkgver and _build variables. just that.

the proposal is not about the pkgver itself - that does not matter. I just wanted a simple cleanup over the AUR to get fewer packages, without duplicates.
of course the maintainer should maintain its PKGBUILD.

I'm talking about these PKGBUILDs for simplicity. i just added the one-liner script to help as a temporary solution to get the latest version.
an example for the opera-qt4 is below

### PKGBUILD ###
pkgname="opera-qt4"
pkgdesc="The Opera web browser - latest final release, for qt4"
url="http://opera.com/"
pkgver='10.10'
pkgrel=1
license=('custom:opera')
arch=('i686' 'x86_64')
makedepends=('gcc-libs')
conflicts=('opera' 'opera-b1' 'opera-beta' 'opera-bundled' 'opera-china-qt3' 'opera-china-qt4'\
'opera-dev' 'opera-devel-qt4' 'opera-dev-qt4' 'opera-g3' 'opera-g4' 'opera-mini' \
'opera-qt3' 'opera-qt4' 'opera-shared-b1' 'opera-static' 'opera-unite-devel-qt3')
provides=('opera')
# check the dependencies according to the machine architecture
[[ "${CARCH}" = "x86_64" ]] && _carch="x86_64" || _carch="i386"
depends=('qt')

source=('opera.desktop')
md5sums=('a31d1d5fd833ee573524cda4b9e9f1ae')
build() {
cd "${srcdir}"
msg2 'Checking the latest final release...' \
# get the filename (_fname)
_fname="opera-${pkgver/b/-b}.gcc4-qt4.${_carch}.tar.gz"
# get the url (_url)
_url="ftp://ftp.opera.com/pub/opera/linux/${pkgver/./}/final/en/${_carch}/${_fname}"
# download the package
msg 'Downloading the source...'
msg2 "${_url}"
wget -q -c "${_url}" -O "${SRCDEST}/${_fname}" || return $?
ln -fs "${SRCDEST}/${_fname}" "${srcdir}/${_fname}" || return $?

msg 'Extracting binaries...'
_dir="$(bsdtar -tzf ${SRCDEST}/${_fname} | head -n 1)" || return $?
bsdtar -xzf ${SRCDEST}/${_fname} || return $?
cd "${_dir}" || return $?

# make the binaries
msg2 'Checking md5sums...'
./install.sh DESTDIR="${pkgdir}" > /dev/null || return $?
msg2 'Installing files...'
install -D -m 444 "LICENSE" "${pkgdir}/usr/share/licenses/opera/license.txt"
install -D -m 644 'usr/share/icons/hicolor/scalable/apps/opera.svg' "${pkgdir}/usr/share/opera/images/opera.svg"
install -D -m 644 "${srcdir}/opera.desktop" "${pkgdir}/usr/share/applications/opera.desktop"
}

then the opera-snapshot-qt4 PKGBUILD should be something as

# WARNING about being a snapshot version (stripped)
### PKGBUILD ###
pkgname="opera-snapshot-qt4"
pkgdesc="The Opera web browser - the latest snapshot build, for qt4"
url="http://opera.com/"
_build='snapshot4744' # <------------- notice this variable is the one which needs to be changed
_pkgver='10.20' # <------------- along with this one
pkgver="${_pkgver}.${_build/-/}"
pkgrel=1
license=('custom:opera')
arch=('i686' 'x86_64')
makedepends=('gcc-libs')
conflicts=('opera' 'opera-b1' 'opera-beta' 'opera-bundled' 'opera-china-qt3' 'opera-china-qt4'\
'opera-dev' 'opera-devel-qt4' 'opera-dev-qt4' 'opera-g3' 'opera-g4' 'opera-mini' \
'opera-qt3' 'opera-qt4' 'opera-shared-b1' 'opera-static' 'opera-unite-devel-qt3')
provides=('opera')
[[ "${CARCH}" = "x86_64" ]] && _carch="x86_64" || _carch="i386"
depends=('qt')
source=('opera.desktop')
md5sums=('a31d1d5fd833ee573524cda4b9e9f1ae')
build() {
cd "${srcdir}"
msg2 'Checking the latest snapshot build...'
_buildver="${_build/*-/}" # the build
_buildtype="${_build/-*/}" # "rc" (release candidate) or "snapshot"
# get the filename (_fname)
_fname="opera-${_pkgver}-${_buildver}.gcc4-qt4.${_carch}.tar.gz"
# get the url (_url)
_url="http://snapshot.opera.com/unix/${_build}/intel-linux/${_fname}"
[[ "${_carch}" != "i386" ]] && _url="http://snapshot.opera.com/unix/${_build}/${_carch}-linux/${_fname}"
# download the package quietly
msg 'Downloading the source...'
msg2 "${_url}"
wget -q -c "${_url}" -O "${SRCDEST}/${_fname}" || return $?
ln -fs "${SRCDEST}/${_fname}" "${srcdir}/${_fname}" || return $?

# extract the source
msg 'Extracting binaries...'
_dir="$(bsdtar -tzf ${SRCDEST}/${_fname} | head -n 1)" || return $?
bsdtar -xzf ${SRCDEST}/${_fname} || return $?
cd "${_dir}" || return $?

# check md5sum and installs the opera package
msg2 'Checking md5sums...'
./install.sh DESTDIR="${pkgdir}" > /dev/null|| return $?
# installs license and the icon file along with the desktop file
msg2 'Installing files...'
install -D -m 444 "LICENSE" "${pkgdir}/usr/share/licenses/opera/license.txt"
install -D -m 644 'usr/share/icons/hicolor/scalable/apps/opera.svg' "${pkgdir}/usr/share/opera/images/opera.svg"
install -D -m 644 "${srcdir}/opera.desktop" "${pkgdir}/usr/share/applications/opera.desktop"
}

edit: the snapshot PKGBUILD may be changed as the opera builder/install-script may also change.

Last edited by quarkup (2009-12-05 10:56:40)

ruario · 2009-12-03 15:03:37

@quarkup: Well then, we all agree ... great!

Heads up though, the PKGBUILD will have to change when we release the new 'install' script. It is rewritten from scratch, with a different name and totally different defaults and install options. This might sound worrying but I'll post a sample PKGBUILD (based off my own internal one) and some more details when we actually release a build with the changes included (sorry, I cannot give a time scale for that).

Actually I think Arch users might appreciate the new install and wrapper ('/usr/bin/opera') scripts as they are far more logical and much simplified (particularly the wrapper), hence more 'Arch like'!

Last edited by ruario (2009-12-03 15:03:58)

quarkup · 2009-12-10 10:38:22

as soon as the install script is changed we should all get the various PKGBUILD and make the change.
although we should get all the opera contributors/maintainers from the actual PKGBUILDS and put them as contributors in the new PKGBUILDS

Shaika-Dzari · 2010-01-02 20:53:00

Hello!

Since I have some problem with opera-g4 and -devel, I have adopted opera-qt3 (http://aur.archlinux.org/packages.php?ID=21390) and bump the version to 10.10.

I did not follow all this thread but feel free to contact me if I need to change or orphan my package to be compliant with your new script.

When do you plan to clean-up all opera package in Aur and use you script?

@+

quarkup · 2010-01-03 13:18:50

actually the opera-g4 script is hardcoded as you can check it's PKGBUILD, it is not KISS-compliant
but those PKGBUILDS above should work somehow..

if the maintainers really need of the PKGBUILD their could just copy these scripts (above) if they really work to make the "change" easier for all

note: actually the PKGBUILDs need to be checked to make sure they work or not.
as soon as possible, and without creating unneeded conflicts, this "change" could be really fast.

Last edited by quarkup (2010-01-03 13:20:43)

Spacecow · 2010-01-05 14:52:00

Hi all,

I have noticed that the pre-alpha release of Opera 10.5 has removed its Qt dependencies:

Our Unix version is undergoing a lot of radical changes for the 10.5 release. It has been mentioned earlier that we are removing our dependency on the Qt libraries. By doing this, we hope to integrate better with the popular desktop environments out there, and we allow Opera to run without the need for a library that might or might not be installed on your system.
This means that you can run Opera without any graphical toolkit installed if you want to (plain X11), but if you do have toolkits installed, Opera will try to load and use them to integrate into the environment. Currently we are focusing on getting support for Gnome/GTK+ and KDE4/Qt4 into 10.5.

Obviously since this is still a pre-alpha there isn't much to be done at this point, but I am just curious; will this change finally spell the end of the confusing array of qt3/qt4 un/bundled packages?

quarkup · 2010-01-05 15:39:05

i hope that happens it will be simplier for one to choose the package .. ^ ^

mjunx · 2010-01-05 16:35:41

So that means that Opera isn't going to drop the use of Qt? Awesome, I was a little scared that yet another GTK application would be made and there'd be no good Qt web browser (and GTK integrates horribly with KDE, but Qt can integrate pretty well with GTK).

ruario · 2010-01-06 10:16:39

It has happened, we removed Qt completely from 10.50 (Evenes). I have known of this for quite a while but sadly couldn't comment publicly until very recently. So the answer to Spacecow's question is yes, no Qt3, Qt4, QtX specific builds and no more bundled builds. Just one build for each processor architecture available as a tarball, .rpm and .deb and possibly another package type or two in the future (No promises or further comments on that right now though!!)

If you want more detail about the removal of Qt read this and this. They are comments from one of our developers who is working on Gtk native integration.

The public pre-alpha does not include the rewrite to install.sh that I alluded to previously. This was delayed slightly whilst we work out some minor issues. Indeed the pre-alpha packages have no install script at all. Though they will run via the included wrapper*. Given the current status of UNIX Evenes I think this is reasonable as you really don't want this as your primary browser (yet).

*The wrapper script is actually the old one, not the streamlined new wrapper mentioned previously, as this is related to the reworking of the install script.

Last edited by ruario (2010-01-06 10:55:57)

flamelab · 2010-01-06 10:19:06

I hope we'll see Opera 10.5 use Qt decoration soon

@ruario: Can we - somehow- force Opera 10.5 to use the GTK2+ decoration? For now, in KDE, it doesn't use any and it has a Win95-like theming (I guess a fallback X theme)

ruario · 2010-01-06 10:28:28

@flamelab: The long term idea is that yes this should be possible if a user desires it but I don't think the preference is integrated yet. I'll check with Arjan to see if there is already a way to do this and I simply missed it.

ruario · 2010-01-06 12:58:22

@flamelab: It should have picked up GTK automatically. Currently (prior to the KDE integration work) as long as the GTK library exists and can be loaded, it should just happen. Possibly the reason it looks bad is that KDE forces a GTK theme that's really ugly. Try running any other GTK application, if you don't see the same then would you mind posting a screen shot somewhere for me?

Edit: Actually you might want to add any follow ups to my blog post as this is off topic from the main thread. Also other's reading that blog post can assist you.

Last edited by ruario (2010-01-06 13:00:50)

Sertse · 2010-01-06 13:30:24

Something more immediate.

I see opera-devel in AUR http://aur.archlinux.org/packages.php?ID=33276 has recently taken over the mantle as the package to use for us who like to follow the devel version? I suppose Arkham who has been doing main/most used opera-devel package up till now http://aur.archlinux.org/packages.php?ID=15228 has been away...

Just when we had some clear hierarchy on what package does what.

Also, I'm don't know if it's been mentioned before, but is it possible somehow to be able to install both stable and dev versions of Opera in aur?

ruario · 2010-01-06 15:26:09

Sertse wrote:

Also, I'm don't know if it's been mentioned before, but is it possible somehow to be able to install both stable and dev versions of Opera in aur?

If you want to run them both, don't install the dev version. Install the stable and run the dev 'in place' from the provided tarball package, e.g if you are using i686 you can download and run the dev version as follows (after first cd'ing to a suitable directory):

curl http://snapshot.opera.com/unix/labs-6177/opera-10.50-6177.linux.i386.tar.bz2 | tar xjf -
cd opera-10.50-6177.linux.i386/
./opera &

This will cause Opera (dev) to create, and use a clean profile directory, which is a subdirectory of opera-10.50-6177.linux.i386/ (i.e. 'opera-10.50-6177.linux.i386/profile') rather than '~/.opera' as it usually does. If you want to test your regular profile, first copy the contents of '~/.opera' to 'opera-10.50-6177.linux.i386/profile'.

I would not recommend running the dev version with your regular profile directly as you have a fair chance of corrupting it. However if you really like to take risks, change the final command in sequence above to:

./opera -pd ~/.opera &

No complaints however if it all goes horribly wrong and you don't have a backup!

quarkup · 2010-01-06 22:13:06

flamelab wrote:

I hope we'll see Opera 10.5 use Qt decoration soon
@ruario: Can we - somehow- force Opera 10.5 to use the GTK2+ decoration? For now, in KDE, it doesn't use any and it has a Win95-like theming (I guess a fallback X theme)

edit: I'm not using opera 10.5 yet

it is working on my kde4

 ~ $ kwin --version
Qt: 4.5.3
KDE: 4.3.4 (KDE 4.3.4)
KWin: 4.3.4 (KDE 4.3.4)

you could just add the -systemstyle flag on opera to get it working, or edit the /usr/bin/opera launcher

exec "${OPERA_BINARYDIR}opera" "$@" -systemstyle "$@"

that is really simple

Last edited by quarkup (2010-01-07 14:49:51)

sr · 2010-01-07 11:34:21

Does anyone else see the 10.50-6177 build look like it's running a single-threaded version? On Arch64, with the 64-bit build, if one of the tabs is loading a webpage (I'm on a slow connection) all the others are unresponsive. I've seen similar behaviour before when I installed a static Qt build by mistake, but that doesn't seem to be the problem.

ruario · 2010-01-07 12:58:10

@quarkup. There is no "-systemstyle" in Evenes.

quarkup · 2010-01-07 14:48:08

ruario wrote:

@quarkup. There is no "-systemstyle" in Evenes.

okay i'm not using that version yet

notice that I'm not 'that guy that will make the change'.

I wanted to propose a more simple and elegant solution to all those different, dupplicated and out-of-date opera packages in our AUR..
without compromising anything.

Last edited by quarkup (2010-01-08 19:22:18)

lustikus · 2010-01-11 12:23:34

Any news on the repackaging of the opera browser?

I did a simple "yaourt -S opera" on a new system yesterday:
1. It did not work. Qt was broken, I had to manually install newest qt to get it running.
2. When you install "opera" you get the newest snapshot of opera, not the stable version. I now have 10.20 which is in a very alpha state.
Some of my mouse buttons don't work and there are several graphical glitches.

Seriously, this has to be fixed asap, opera deserves a well maintained package in [extra]

whompus · 2010-01-11 13:30:00

The default option for opera is the devel snapshot version, you need to change the option in the PKGBUILD to get the latest stable version.

lustikus · 2010-01-11 17:03:55

whompus wrote:

The default option for opera is the devel snapshot version, you need to change the option in the PKGBUILD to get the latest stable version.

this is just what I mean.
A Package with no *dev, *git, *snapshot etc in its name is supposed to be the latest stable release.

Arch Linux

#51 2009-11-26 17:18:22

Re: [proposal] The Opera browser

#52 2009-11-26 17:51:03

Re: [proposal] The Opera browser

#53 2009-11-30 18:40:34

Re: [proposal] The Opera browser

#54 2009-12-03 09:41:57

Re: [proposal] The Opera browser

#55 2009-12-03 11:53:15

Re: [proposal] The Opera browser

#56 2009-12-03 15:03:37

Re: [proposal] The Opera browser

#57 2009-12-10 10:38:22

Re: [proposal] The Opera browser

#58 2010-01-02 20:53:00

Re: [proposal] The Opera browser

#59 2010-01-03 13:18:50

Re: [proposal] The Opera browser

#60 2010-01-05 14:52:00

Re: [proposal] The Opera browser

#61 2010-01-05 15:39:05

Re: [proposal] The Opera browser

#62 2010-01-05 16:35:41

Re: [proposal] The Opera browser

#63 2010-01-06 10:16:39

Re: [proposal] The Opera browser

#64 2010-01-06 10:19:06

Re: [proposal] The Opera browser

#65 2010-01-06 10:28:28

Re: [proposal] The Opera browser

#66 2010-01-06 12:58:22

Re: [proposal] The Opera browser

#67 2010-01-06 13:30:24

Re: [proposal] The Opera browser

#68 2010-01-06 15:26:09

Re: [proposal] The Opera browser

#69 2010-01-06 22:13:06

Re: [proposal] The Opera browser

#70 2010-01-07 11:34:21

Re: [proposal] The Opera browser

#71 2010-01-07 12:58:10

Re: [proposal] The Opera browser

#72 2010-01-07 14:48:08

Re: [proposal] The Opera browser

#73 2010-01-11 12:23:34

Re: [proposal] The Opera browser

#74 2010-01-11 13:30:00

Re: [proposal] The Opera browser

#75 2010-01-11 17:03:55

Re: [proposal] The Opera browser

Board footer