[proposal] The Opera browser

quarkup · 2010-01-11 23:29:45

i agree

IMO the packages should be named something like

opera
opera-snapshot
opera-beta (if it is really needed)

etc...
now there are major changes in the opera packages (qt/gtk, etc...) so im not really thinking to change anything before the official release of the opera 1.50 or any more advanced builds.

ruario · 2010-03-21 00:00:38

You might want to read this blog post:

http://my.opera.com/ruario/blog/new-ope … eb-rpm-tar

Particularly the end, where I talk about repackaging Opera and even provide a sample PKGBUILD.

flamelab · 2010-03-21 05:49:16

ruario wrote:

You might want to read this blog post:
http://my.opera.com/ruario/blog/new-ope … eb-rpm-tar
Particularly the end, where I talk about repackaging Opera and even provide a sample PKGBUILD.

Thanks for the PKGBUILD ;p

Last edited by flamelab (2010-03-21 05:52:40)

flamelab · 2010-03-21 06:07:00

I can't write ANY greek word within Opera

The letters appear like hieroglyphics:

ߊߡ߫ߧ߬߱ߡ

:-/

Last edited by flamelab (2010-03-21 06:07:20)

ruario · 2010-03-21 08:50:56

This is a known bug. It'll be fixed but you should probably stick to the stable branch for now.

ruario · 2010-03-22 15:38:05

I'd be interested to know what other Arch users felt about the relatively 'simplicity' of these two PKGBUILDS

The reason I ask is because I am trying to convince totoloco (maintainer of opera-devel) to use the first method, mainly to save him a load of hassle in the future!

pkgname=opera
pkgver=10.51
_buildver=6252
pkgrel=4
pkgdesc="A fast and secure web browser and Internet suite"
url="http://www.opera.com/browser/"
depends=('freetype2' 'gcc-libs' 'glibc' 'gstreamer0.10-good' 'libice' 'libx11' 'libxext' 'libxft' 'libxrender' 'zlib')
license=('custom:opera')
arch=('i686' 'x86_64')
source=(http://snapshot.opera.com/unix/snapshot-${_buildver}/opera_${pkgver}-${_buildver}_i386.deb)
md5sums=('e03e6297b461a964a4b092be9c535bab')

[ "$CARCH" = "x86_64" ] && source=(http://snapshot.opera.com/unix/snapshot-${_buildver}/opera_${pkgver}-${_buildver}_amd64.deb)
[ "$CARCH" = "x86_64" ] && md5sums=('c7cc8a617b9f75f46686164de09497cb')

build() {
if [ "$CARCH" = "x86_64" ]; then 
    bsdtar xOf opera_${pkgver}-${_buildver}_amd64.deb data.tar* | bsdtar xf - -C ${pkgdir} --exclude changelog.Debian.gz --exclude lintian
 else    bsdtar xOf opera_${pkgver}-${_buildver}_i386.deb data.tar* | bsdtar xf - -C ${pkgdir} --exclude changelog.Debian.gz --exclude lintian
fi
install -D -m 644 ${pkgdir}/usr/share/opera/defaults/license.txt ${pkgdir}/usr/share/licenses/opera/license.txt
}

versus:

# Contributor: totoloco <totoloco en gmail>
# using ruario's build
pkgname=opera-devel
_buildver=6252
_bigrelease=10.51
pkgver=${_bigrelease}_${_buildver}
pkgrel=6
pkgdesc="A fast and secure web browser and Internet suite"
url="http://www.opera.com/browser/"
depends=('freetype2' 'gcc-libs' 'glibc' 'gstreamer0.10-good' 'libice' 'libx11' 'libxext' 'libxft' 'libxrender' 'zlib')
license=('custom:opera')
arch=('i686' 'x86_64')
source=(http://snapshot.opera.com/unix/snapshot-${_buildver}/opera-${_bigrelease}-${_buildver}.i386.linux.tar.bz2)
md5sums=('c462b6dcb10e27ad869496b0f24fb3fb')
provides=('opera')
conflicts=('opera')

[ "$CARCH" = "x86_64" ] && source=(http://snapshot.opera.com/unix/snapshot-${_buildver}/opera-${_bigrelease}-${_buildver}.x86_64.linux.tar.bz2)
[ "$CARCH" = "x86_64" ] && md5sums=('a5a5d6cfa0204436eb632940e3673647')

build() {
  if [ "$CARCH" = "x86_64" ]; then
    cd ${srcdir}/opera-${_bigrelease}-${_buildver}.x86_64.linux
    else  cd ${srcdir}/opera-${_bigrelease}-${_buildver}.i386.linux
  fi
  
  # Create initial directory structure
  
  mkdir -p ${pkgdir}/usr/bin
  
  # Create 'opera' and 'opera-widget-manager' wrapper scripts and make them executable
  
  cat <<EOF > ${pkgdir}/usr/bin/opera
#!/bin/sh 
export OPERA_DIR=\${OPERA_DIR:-/usr/share/opera} 
export OPERA_PERSONALDIR=\${OPERA_PERSONALDIR:-\$HOME/.opera} 
exec /usr/lib/opera/opera "\$@"
EOF

  cat <<EOF > ${pkgdir}/usr/bin/opera-widget-manager
#!/bin/sh 
exec /usr/bin/opera --widgetmanager "\$@"
EOF

  chmod 755 ${pkgdir}/usr/bin/opera*
  
  # Copy over 'lib/' and 'share/'
  
  cp -R lib ${pkgdir}/usr/
  cp -R share ${pkgdir}/usr/
  
  # Patch variables in the *.desktop and man files to reflect the final install location.
  
  sed -i ${pkgdir}/usr/share/applications/opera-browser.desktop -e "s|\@\@{PREFIX}|/usr|" -e "s|\@\@{[U_]*SUFFIX}||"
  sed -i ${pkgdir}/usr/share/applications/opera-widget-manager.desktop -e "s|\@\@{PREFIX}|/usr|" -e "s|\@\@{[U_]*SUFFIX}||"
  gzip -d ${pkgdir}/usr/share/man/man1/opera.1.gz
  sed -i ${pkgdir}/usr/share/man/man1/opera.1 -e "s|\@\@{PREFIX}|/usr|" -e "s|\@\@{[U_]*SUFFIX}||"
  gzip -d ${pkgdir}/usr/share/man/man1/opera-widget-manager.1.gz
  sed -i ${pkgdir}/usr/share/man/man1/opera-widget-manager.1 -e "s|\@\@{PREFIX}|/usr|" -e "s|\@\@{[U_]*SUFFIX}||"
  sed -i ${pkgdir}/usr/share/mime/packages/opera-widget.xml -e "s|@@{[U_]*SUFFIX}||"

  # Place the license in the standard Arch location.
  
  install -D -m 644 share/doc/opera/LICENSE ${pkgdir}/usr/share/licenses/opera/license.txt
}

Both were initally written by me (though the second has since been tweaked by totoloco). I wrote them to demonstrate possible methods of creating a PKGBUILD without using our new install script (since it has no '--prefix' option and can only install to two set directories, which is hardly ideal for wrapping everything up in PKGBUILD).

Personally I feel that the first is simpler and hence is more 'Arch like'. It might initially feel wrong because I use the .deb file as a base rather than a tarball. However, I do this specifically because our .deb files are easier/simpler than the tarballs we provide (even if this is not generally the case). Additionally, whilst .deb files themselves are arguably over complex for software packaging, the first PKGBUILD does not need to understand or interpret any of the Debian meta information. All of this is simply ignored. I just pull out the 'data.tar.gz' part (which is a regular tarball) and then use this to obtain the correct layout for a final install. The beauty of this solution is that bsdtar is able to read 'ar' archives and .deb files are just 'ar' archives containing three files (two contain meta information, the other is 'data.tar.gz'). (In case anyone is unaware of how I am able to assume bsdtar will be present, it is because bsdtar is provided by the libarchive package and pacman itself depends on libarchive).

In the second PKGBUILD however, I need to create two startup wrapper scripts (one for Opera itself and one for our Widget Manager) and I must patch numerous files. The problem (in terms of maintenance going forward) is that it is quite reliant on us not making any further changes to the tarball layout or the installer script (which trust me, could easily happen). On the other hand the 'data.tar.gz' part of .deb will always reflect the correct final layout and hence is stable, and this is the only part that the first PKGBUILD needs or uses.

Last edited by ruario (2010-03-22 19:51:49)

ruario · 2010-03-23 11:26:33

I have decided to add my own PKGBUILD on the AUR again (this time called 'opera-snapshot').

mjunx · 2010-03-23 15:21:28

I like the simplified PKGBUILD. However, sure, bsdtar is provided like that, but it wouldn't hurt to add libarchive to the makedepends array, even if it's only to make namcap happy. Besides, what if pacman doesn't depend on libarchive one day?

ruario · 2010-03-24 12:59:41

@mjunx: Next time we release a snapshot I'll update it to add libarchive to the makedepends. Though I don't think it is really necessary as makepkg itself uses bsdtar for opening tarballs and also there is no complaint from namcap about this.

But I can add it to 'make mjunx happy'.

ruario · 2010-04-06 13:26:04

Ok, I took over opera-devel from totoloco and hence dropped 'opera-snapshot' (since I suspected that more people were using opera-devel).

@mjunx: done in opera-devel.

@quarkup: So we are now down to just two versions: stable and development (which could be snapshot or beta, whichever is most recent). Looks like we have finally made it a simple choice between two packages.

I am considering adding one more package however. It would be the same as -devel but with renamed resources and set to use a different profile directory, hence allowing a side by side installation of the development version and the stable branch. This is handy when people want to try before committing to an upgrade. Indeed, we have something like this in our official tarball packages, when using our new install script (see the 'suffix' install option).

On the other hand, it would be another package to maintain and you could easily argue that this is not required and only serves to muddy the neat two package options we now have. Additionally, if people really want side by side installs they already have to good options:

They can run Opera 'in place' e.g.,

$ tar xf opera-10.52-6302.i386.linux.tar.bz2 
$ opera-10.52-6302.i386.linux/opera &

This will keep the profile/settings, within the extracted directory

Or they could use the install script directly with the downside being that the install is outside of pacman (though we do provide our own uninstall script).

Nonetheless, I would be interested to know people's thoughts.

Regarding the licensing, we're still looking at this internally. If we can get that resolved in a satisfactory way then perhaps we can get Opera back in one of the official repositories one day. However, I am not promising anything.

P.S. Those wondering about the bug that flamelab mentions. It is fixed!

Last edited by ruario (2010-04-06 13:32:04)

quarkup · 2010-04-06 13:32:59

okay, even today I am going to check opera in linux, and check changes

ruario · 2010-04-06 13:37:17

quarkup wrote:

okay, even today I am going to check opera in linux, and check changes

I'm assuming you will use a PKGBUILD so remember to backup your profile as you might have trouble going backwards, or at the very least run Opera 'in place' first via an extracted official tarball, which you can get from:

http://my.opera.com/desktopteam/blog/20 … r-holidays

I list the major known issues in that blog post (though it is by no means a complete list). If you see bugs not listed that you want to report, this is our bug reporting page.

Last edited by ruario (2010-04-06 13:49:17)

hullap · 2010-04-06 13:51:58

ruario wrote:

Regarding the licensing, we're still looking at this internally. If we can get that resolved in a satisfactory way then perhaps we can get Opera back in one of the official repositories one day. However, I am not promising anything.

We hope it gets there

ruario · 2010-05-03 00:10:11

Ok, we now have an updated EULA for Opera Desktop Browser for Open Source Operating Systems. I'd be interested to here what people think.

http://my.opera.com/ruario/blog/show.dml/10870581

Shaika-Dzari · 2010-05-03 00:34:09

Hello ruario,

I'm not a license specialist but if this license is more open source friendly, could you submit it to Archlinux developer (Mailing list or bug report) ?
I would be happy to see opera available in [extra] again

@+

skottish · 2010-05-03 00:35:34

Arch-Opera users: If this license looks good, then one of you should file a feature request explaining that the licensing is no longer a concern for Arch. There are no ideological problems in the way if this is the case.

ruario · 2010-05-04 10:02:41

Shaika-Dzari wrote:

I'm not a license specialist but if this license is more open source friendly, could you submit it to Archlinux developer (Mailing list or bug report) ?

I will do this at some point. However, first I want to consider some of the other feedback we have received.

@all: I decided to create opera-beta in addition to opera-devel to track Beta releases. Although Opera development snapshots will always have the latest fixes and improvements, they do not undergo the same amount of regression testing that a Beta release does. As such, whilst in all likelihood opera-devel will 'probably' be better in terms of features and fixes it has the potential to be more broken. Opera Beta (whilst often behind the snapshot) is more of a known quantity.

Pierre · 2010-05-04 10:33:10

I am just wondering how we could add the certs from cacert.org globally/system-wide to opera. That's what we use for https here and every browser in our repos should have these installed. (it would be best to make it use the system certs store at /etc/ssl/certs)

Arch Linux

#76 2010-01-11 23:29:45

Re: [proposal] The Opera browser

#77 2010-03-21 00:00:38

Re: [proposal] The Opera browser

#78 2010-03-21 05:49:16

Re: [proposal] The Opera browser

#79 2010-03-21 06:07:00

Re: [proposal] The Opera browser

#80 2010-03-21 08:50:56

Re: [proposal] The Opera browser

#81 2010-03-22 15:38:05

Re: [proposal] The Opera browser

#82 2010-03-23 11:26:33

Re: [proposal] The Opera browser

#83 2010-03-23 15:21:28

Re: [proposal] The Opera browser

#84 2010-03-24 12:59:41

Re: [proposal] The Opera browser

#85 2010-04-06 13:26:04

Re: [proposal] The Opera browser

#86 2010-04-06 13:32:59

Re: [proposal] The Opera browser

#87 2010-04-06 13:37:17

Re: [proposal] The Opera browser

#88 2010-04-06 13:51:58

Re: [proposal] The Opera browser

#89 2010-05-03 00:10:11

Re: [proposal] The Opera browser

#90 2010-05-03 00:34:09

Re: [proposal] The Opera browser

#91 2010-05-03 00:35:34

Re: [proposal] The Opera browser

#92 2010-05-04 10:02:41

Re: [proposal] The Opera browser

#93 2010-05-04 10:33:10

Re: [proposal] The Opera browser

Board footer