Opera soon back in repositories!

Duologic · 2010-05-20 15:59:23

Hi all

I stumbled across following article: http://my.opera.com/ruario/blog/show.dml/10870581
It talked about a change in Opera's EULA so Open Source OSes may (re)distribute Opera.

It is not yet in the stable release, but it will in the future. (now in snapshot 6330)

The relevant part in the license (found here: http://snapshot.opera.com/unix/snapshot-6330/LICENSE)

...
2. LICENSE. Subject to the terms and conditions of this Agreement, Opera hereby grants
Customer a limited, non-exclusive, non-transferable, non-sublicensable license: (i) to use
the Services and to install and Use the Software supplied to Customer hereunder, as
installed on your personal computer, including your laptop, desktop or on computers within
Customer's organization; and (ii) to reproduce and distribute the Software without
modification, provided that any such reproduction or distribution of the Software by You:
(i) must be in an application repository for a desktop Open Source OS distribution
(expressly excluding distribution for embedded Open Source OS); (ii) must be made available
free of charge for end-users; and (iii) must be subject to and distributed with a copy of
this Agreement.
...

I myself won't use it because I install the latest snapshots, but there will be a few people around that like this.

Borosai · 2010-05-20 16:55:53

I hope so.

Bestiapeluda · 2010-05-20 17:37:46

Great !!

Mr.Elendig · 2010-05-22 12:33:35

Still troublesome, depending on how exactly they define "without modification".

Duologic · 2010-05-22 12:45:56

I bet we don't modify the code or artwork.

Edit: see http://aur.archlinux.org/packages/opera … l/PKGBUILD

Last edited by Duologic (2010-05-22 12:48:33)

Awebb · 2010-05-22 17:32:19

Duologic wrote:

Edit: see http://aur.archlinux.org/packages/opera … l/PKGBUILD

What's the benefit of using the rpm vs. the tarball?

Last edited by Awebb (2010-05-22 17:33:06)

Duologic · 2010-05-22 17:45:39

You can also get the tarball, why use one or the other is not for me to discuss.

MindTooth · 2010-05-25 20:46:00

I vote for this aswell

ruario · 2010-05-26 18:34:16

Mr.Elendig wrote:

Still troublesome, depending on how exactly they define "without modification".

To be honest I need to get someone to clarify that for me as well.

Whilst I am an Opera employee in the *nix desktop team, I don't really get involved in license creation (outside of a little feedback from time to time). This is done by our legal team. Also it is been some time since I last spoke to the primary license author about what is intended, since I have been busy working towards a 10.5x release. That said, I can give you my thoughts 'as a regular user'. I do wonder if perhaps the key part is this:

1.4 "Software" means the proprietary Opera software products (in object code format only)...

That seems to imply that you cannot modify the executable files, hence should not preclude repackaging. I readily confess however that I am no expert in this field, so don't give my opinion too much weight.

Awebb wrote:

Duologic wrote:
Edit: see http://aur.archlinux.org/packages/opera … l/PKGBUILD
What's the benefit of using the rpm vs. the tarball?

As you are probably aware .rpm files are really just compressed cpio archives with a modified header containing various information that is used by the RPM package manager (see Wikipedia's RPM article for more information). Tools like rpm2cpio work by simply stripping off the header and decompressing leaving just the internal cpio file. Once you ignore all the RPM specific packaging stuff (which is obviously redundant on Arch), .rpm is basically just another archive format. So I could rephrase your question to "What's the benefit of using the cpio archive (rpm) vs. the tar archive?"

Well both archive formats are equally well supported on Arch due to the fact that all Arch installs include tar and bsdtar. Both can obviously open tar archives and the latter can open cpio archives as well. Indeed bsdtar has an extra trick up its sleeve in that it can open a .rpm file directly by ignoring the RPM specific stuff in the header and treating the file as a regular compressed cpio file. As to why bsdtar is always present on Arch, this is due to the fact that it is provided by the libarchive package and pacman in turn depends on libarchive (which it uses for opening Arch packages). So in terms of easy extraction of contents there is nothing to choose between our .rpm/.cpio archive and our .tar archives. Additionally I can also confirm that the binary files within the rpm/cpio file and our tar files are identical, having been built on the same build server. So initially it might seem there is little reason to choose one over the other.

Though whilst the binaries are the same, the contents are not entirely the identical. The tar packages are laid out in way that makes it possible for users to unpack them and run them in place (without install), rather than conforming to FHS. They also include an install script that will shift around the arrangement of files for side by side installs and/or installs into a couple of different locations either /usr/local or ~/.local (these final installs will confirm to FHS). This makes the tar packages ideal for testing and for distros where no native package is available. However it makes them more of a pain to work with for the purposes of repackaging into another package format, since your goal is to recreate the final install layout within $pkgdir. To achieve this with the tar packages you need to shift around their contents manually and patch a few text files (the startup scripts, *.desktop, MIME and man files) to set internal install locations to /usr. Alternatively you can patch the install location of the install script to force it to 'install' to $pkgdir, rather than /usr/local or ~/.local. However, even that is not enough as you also have to patch it in a couple of other places as well: to ensure so that those text files show the 'final' location (/usr rather than $pkgdir), and to prevent calls to external utilities such as update-desktop-database and update-mime-database since they are not appropriate during a repackaging step. Only then can you safely call the install script and trust it to do the right thing. Hence the tar packages require much more effort to repackage well.

Currently I maintain all the Opera 10.5x (codename Evenes) packages on the AUR: opera-devel, opera-beta and opera-labs-webm. Given I am very familiar with Opera's packaging methods I could easily use either package and one might argue that despite the extra hassle I should use the tar packages as a base since this is the 'norm'. However, I maintain these PKGBUILDs in an unofficial capacity and as such I might not always remain the maintainer. I therefore feel it is my duty to use the simplest method. The "Arch way" encourages this for good reason. In the case of these three PKGBUILDs, it reduces the burden on anyone who might take over from me, both in terms of them understanding the current method and also because that they do not have to closely track any changes we make to the layout of tar packages or install script in the future. Consider that changes to either might cause a PKGBUILD to break. Compare this with a single command of 'bsdtar xf opera-${_bigrelease}-${_buildver}.${_arch}.rpm -C ${pkgdir}', which is very reliable and is not likely to ever cause a problem.

Anyway, I hope that answers your question!

P.S. Unlike for the opera-devel and opera-beta PKGBUILDs, I was forced to use the tar package as a source for opera-labs-webm since we did not produce any .rpm packages on that occasion. That was a one off due to special circumstances (which I seriously doubt we will repeat in the future). However, for now it allows you to compare the two methods. You'll note that I put comments in opera-labs-webm explaining the steps, whilst for opera-devel and opera-beta I haven't bothered as I figure people won't have too many problems understanding the 'build' section.

Last edited by ruario (2010-05-26 19:02:48)

ruario · 2010-05-26 18:50:46

If you are interested in our packages and/or repackaging you might also want to read this.

Duologic · 2010-05-26 19:44:45

Terrific information Ruario, I read your blog posts regularly too. Now I can discuss about this.

Shaika-Dzari · 2010-05-30 14:25:10

Hello!

A simple Up! I'm sure a lot of people want opera to be in community.

The only modification archlinux may have to do is the specific pacman packaging. I'm sure the artwork or the code will not be modified.

Regards.

ruario · 2010-05-31 11:44:30

Shaika-Dzari wrote:

The only modification archlinux may have to do is the specific pacman packaging.

That is what I would have thought as well and I don't think we intent to prevent this but I still have not spoken with the licensing team. I'm quite rushed at the moment as we are attempting to get 10.60 up to final quality really soon and bring out a new stable.

P.S. I adjusted the opera-devel PKGBUILD to include some comments about using the .rpm instead of the .tar packages. I also switched to using bsdcpio (instead of bsdtar) for package extraction. This isn't really necessary since bsdtar and bsdcpio support extracting exactly the same types of archives (they are both libarchive based) but I hope it gives a better hint at what is going on, i.e. I am actually taking the contents from a cpio file (that happens to reside within a .rpm).

Last edited by ruario (2010-05-31 11:44:52)

Mr.Elendig · 2010-05-31 12:20:05

ruario wrote:

To achieve this with the tar packages you need to shift around their contents manually and patch a few text files (the startup scripts, *.desktop, MIME and man files) to set internal install locations to /usr. Alternatively you can patch the install location of the install script to force it to 'install' to $pkgdir, rather than /usr/local or ~/.local. However, even that is not enough as you also have to patch it in a couple of other places as well: to ensure so that those text files show the 'final' location (/usr rather than $pkgdir), and to prevent calls to external utilities such as update-desktop-database and update-mime-database since they are not appropriate during a repackaging step. Only then can you safely call the install script and trust it to do the right thing. Hence the tar packages require much more effort to repackage well.

The big question is if doing things like this do count as "without modification" or not.

Going to be intresting to hear what the legal department thinks about it

Personally, I think opera should get a install script that has a --destdir option. That would make it much nicer to repackage.

ruario · 2010-05-31 12:47:22

Mr.Elendig wrote:

The big question is if doing things like this do count as "without modification" or not.
Going to be intresting to hear what the legal department thinks about it

Yep

Mr.Elendig wrote:

Personally, I think opera should get a install script that has a --destdir option. That would make it much nicer to repackage.

True it would be better but I don't think we'll have time for this before the 10.60 final. Additionally I don't believe it is necessary for the purposes of creating an Opera PKGBUILD, even one that moves into community or extra. Surely using the .rpm as a 'source' packages is enough.

In PKGBUILDS you should always have your PKGBUILD start with an official 'raw package' from the developer. For FOSS software obviously this official package is a true source package (i.e. one that contains the original unmodified source code provided by the developer), usually wrapped up in a tarball. However for proprietary software like Opera there is no publicly available true source package. The official 'raw package' is therefore equally the tar, rpm or deb. One is no more valid than the other. Hence you are free to take your pick for the 'source' of the PKGBUILD.

Hence I see no problem with using the .rpm over the .tar for a 'source' package within the PKGBUILD. All it results in as an easier to understand and easy to modify PKGBUILD, with less chance of things going wrong.

Mr.Elendig · 2010-05-31 14:52:31

I was thinking a bit whider than just packaging in arch There is always someone that for some reason needs a bit more "exsotic" placement than /usr or /usr/local

ruario · 2010-05-31 16:39:19

Yeah, it is a fair point. Though whilst not ideal for repackaging, the install script does do a few nice things though, like giving you the possibility of multiple side by side installs in either /usr/local or ~/.local/ via our suffix option (each using a different unique profile). Installing in these locations (rather than prefixing elsewhere) means that you will get full desktop integration.

Although I wrote and maintain the PKGBUILD I never use it since I always have multiple copies of Opera installed. Indeed at this moment in time I have 178 copies of Opera on my main machine (primarily for regression testing). In truth only one of these is installed (in ~/.local). The rest are just unpacked and I run them in place via the shell script in the top level extracted directory.

Last edited by ruario (2010-05-31 16:58:49)

Awebb · 2010-06-10 14:22:24

ruario wrote:

If you are interested in our packages and/or repackaging you might also want to read this.

Thanks alot, this has really enlightened me :-)

EDIT:
I just had some kind of magic moment in my own little tradition of computing. I write a single line out of pure curiosity without any hints of criticism and something gets changed, even if it's just a comment in a build script. I'm usually told to gtfo or do it better or get flamed, but this time, two of my favorite pieces of software, Arch and Opera, showed me that 'community' is more than an euphemism for trolls and leechers. I love this mentality of watching ideas actually go upstream instead of hiding them in a textfile on a floppy in a safe in the basement.

Very well played

Last edited by Awebb (2010-06-10 19:17:08)

lastchancetosee · 2010-06-20 12:45:51

Hooray!
It would be great if these licensing issues were resolved soon. Opera is too good to be excluded from [extra]/[community].

ruario · 2010-06-30 20:46:39

Mr.Elendig wrote:

I was thinking a bit whider than just packaging in arch There is always someone that for some reason needs a bit more "exsotic" placement than /usr or /usr/local

If you want to put it somewhere else then all you need to do is unpack the .rpm to your selected location and the and then edit the three lines in [...]usr/lib/opera/opera to reflect this new location.

Last edited by ruario (2010-06-30 20:48:07)

Shaika-Dzari · 2010-08-09 23:01:29

Do you have some news on the licensing issue Ruario?

Last edited by Shaika-Dzari (2010-08-09 23:01:48)

Arch Linux

#1 2010-05-20 15:59:23

Opera soon back in repositories!

#2 2010-05-20 16:55:53

Re: Opera soon back in repositories!

#3 2010-05-20 17:37:46

Re: Opera soon back in repositories!

#4 2010-05-22 12:33:35

Re: Opera soon back in repositories!

#5 2010-05-22 12:45:56

Re: Opera soon back in repositories!

#6 2010-05-22 17:32:19

Re: Opera soon back in repositories!

#7 2010-05-22 17:45:39

Re: Opera soon back in repositories!

#8 2010-05-25 20:46:00

Re: Opera soon back in repositories!

#9 2010-05-26 18:34:16

Re: Opera soon back in repositories!

#10 2010-05-26 18:50:46

Re: Opera soon back in repositories!

#11 2010-05-26 19:44:45

Re: Opera soon back in repositories!

#12 2010-05-30 14:25:10

Re: Opera soon back in repositories!

#13 2010-05-31 11:44:30

Re: Opera soon back in repositories!

#14 2010-05-31 12:20:05

Re: Opera soon back in repositories!

#15 2010-05-31 12:47:22

Re: Opera soon back in repositories!

#16 2010-05-31 14:52:31

Re: Opera soon back in repositories!

#17 2010-05-31 16:39:19

Re: Opera soon back in repositories!

#18 2010-06-10 14:22:24

Re: Opera soon back in repositories!

#19 2010-06-20 12:45:51

Re: Opera soon back in repositories!

#20 2010-06-30 20:46:39

Re: Opera soon back in repositories!

#21 2010-08-09 23:01:29

Re: Opera soon back in repositories!

Board footer