rpm requires seamonkey
 

There is a "standalone seamonkey-solibs package for RPM, gxine, etc". But after recent upgrades in -current, i can't use rpm without full seamonkey package installed. Can someone revise the contents of seamonkey-solibs and add missing files to it?

$ LANG=C rpm -qp --qf %{NAME} opera-11.00-1156.i386.rpm
error: opera-11.00-1156.i386.rpm: Header SHA1 digest: BAD
error: opera-11.00-1156.i386.rpm: not an rpm package (or package manifest)

And `rpm2txz -nd opera-11.00-1156.i386.rpm` doesn't work as expected without seamonkey package installed.

Thanks

why do you use RPM package for Opera when there's an Opera installer for Slackware?
http://slackblogs.blogspot.com/2010/...-released.html

Generally : Using rpm packages is absolutely "last resort"

Tons of Slackbuilds out there : http://slackbuilds.org/

And : Example ... http://www.slacky.eu/

EDIT :
Sorry, I wasn't aware, that SlackBuild.org uses rpm packages as source for Opera.
Ref. post # 8.
..

Some applications are closed-source, so you can not build good package anyway. It's much easier to just convert rpm package to txz in this case. And i think that this situation with rpm and seamonkey shows, that seamonkey-solibs package is incorrect and don't meet requirements.
I'm asking someone to revise and correct seamonkey.SlackBuild and i don't need advice about installing packages.

I found the cause of this issue.
The seamonkey-solibs package is missing a library file: /usr/lib64/seamonkey-2.1b1/libmozsqlite3.so ... Once that file is added, rpm works again without the need for the full seamonkey package.

I have notified Pat V. so that he can release an updated package which fixes the issue.

Eric

Thank you, Eric.

fixed in the last update

SlackBuild and Opera11
 

The SlackBuild.org uses the rpm package as source of Opera.

(see http://slackbuilds.org/repository/13.1/network/opera/)

A guess at why the Opera Slackbuild uses the rpm
 

Firstly I should state I am an Opera employee working in the Linux/FreeBSD team. I have also given advice to maintainers in the past to help them repackage Opera so I think I can make a fair guess at why the Opera Slackbuild uses the rpm as a source.

I suspect the reason is that as of Opera 10.51 we rewrote the install script that was included with our generic (cross distro) tar packages, along with major changes to our deb and rpm packages. Whilst on the hole these new packages where a vast improvement, they were sadly lacking in at least one area. The first implementation of the install script could only install to two fixed locations, so it was not really ideal for repackaging into another format. At the time, myself and my colleagues therefore suggested three workarounds:

1. Use the rpm or deb packages as a source (for now)
2. Patch the install script to allow for installation to another location (the repack staging directory)
3. Manually shift around the package contents and patch various files.

Using the rpm or deb packages as a source was our preferred method, because although far from ideal it had the least chance of going wrong. ;)

As of Opera 11 we fixed the issue with the install script and now recommend this packages are used as a source for repackaging. It also has an extra advantage over the rpms for distros that have a local repackaging solution (Slackbuilds, Gentoo ebuilds, Arch PKGBUILDs, etc.), in that it is a smaller file for the end user to download. So in summary it looks like the SlackBuild is just a variant of the previous one where using the rpm as a base probably was the best option. I have since dropped an email to the maintainer and let him know that he could now use the tar packages if he so desires.

On a related note, I have written a couple of demo Slackware build scripts. One using a 'Salix-style' Slkbuild script to repackage Opera and another that is a simple shell script that converts any recent Opera tar package you feed it into Slackware format. The latter has the advantage that it is not tied to any one version so doesn't need to be maintained as regularly and hence could be used to repackage any of our development builds (a.k.a. Opera snapshots) into Slackware format. I have also provided an option to allow for side by side installs of the stable and development builds by setting a variable in the script.

Anyway, if the rpms as a source bothers you, try one of these or use them to get ideas to write your own build script for Opera.

As a side note, if you are less fussy about having to have a native package our install script will install directly on Slackware (and pretty much any modern distro) and will create an uninstall script for clean removal. It also supports many options such as, single user (as well as system wide) installs and 'suffix' installs that allow multiple copies of Opera to run side by side (with there own profiles/settings). In both cases Opera will be fully integrated with any Desktop environment you might have running. To use the install script, simply unpack the tar, cd into the created directory and issue './install --help' to see what options are available. Or just run it as './install' as it has a nice interactive step by step install.

> if the rpms as a source bothers you

Not at all :) I use one single command to convert opera rpm package to slackware package. Using your scripts requires more action.

Ruario, if you are looking for areas where you can improve opera users experience, i can say that the two major problems with opera for me are:

• operas window freezes for a while when i dragging something from dolphin to it.
• youtube works really bad. Webm works only for first video, than something happens with cookies and i should remove all youtube cookies to be able to watch other video. And gnash works fine only in firefox; neither opera nor rekonq can work with gnash properly.

Are you sure that's not a kde problem GArik? Opera 11 opens .html docs I drag from thunar instantly.

I just tried it on my system.. Opera 11 with KDE 4.5.4 and it worked instantly..

That isn't really true:

('op2slk' being the name of my last example script)

and you end up with a copy of Opera 11 repacked. Surely that is one single action? And without the reliance on a third party tool like rpm. Your problems with rpm where why you started this thread after all. ;)

That being said, if you have a solution that already works for you by all means use it. I wrote the Slkbuild scripts to save maintainer's time as it was a good way to demonstrate the new preferred method of of repacking Opera. Allowing the Salix guys (and any one else using Slkbuild) to lift the example either directly or cherry pick anything they found useful. Previously, because the install script lacked a --repackage option they had chosen to use the "3. Manually shift around the package contents and patch various files." method. The reason for patching various files was because the contents of our tar files are designed to be processed by our install script (to allow for more complex install options like suffix installs). However if you don't use the script you must process them yourself. Since the contents of the package change, the files you need to process can as well. As a result the Salix Opera package created by Slkbuild was slightly broken as they missed a few files. The other advantage of using the install script directly is that it checks the m5dsum of every single file that the tar ball contains and will error if any are corrupted. This means that you don't have to have your own check of the source package before you begin.

My 'op2slk' script was written as a more general demonstration of how to repack Opera without using tools like Slkbuild. You only need to change the first part to hard code certain variables (rather than pick them up from the Opera package name) if you wanted to make something that starts to look more like a traditional build script.

As for automatic conversion with a generic tool like alien or others, sure this works and the packages produced are generally good enough but often don't take into account some Slackware specifics, like say location of the man and doc directories or consider that you should really but libs in /usr/lib64 on a 64bit Slack install. My op2slk script also provides a couple of Opera Specific options as well. In the case of op2slk you can set a couple of variables to gain some niceties. One makes use of our install script's suffix option to allow you to have multiple packages of Opera that run side by side with no clashing files or profiles. This is handy if you like to run development builds of Opera. The other allows for automatic customisation of Opera's User Agent to include you distro name. Handy on sites like LinuxQuestions. More importantly that one gives a hint that customisation of Opera prior to packaging is possible (indeed you can preset almost any pref, include skin files, toolbars, bookmarks, etc.), which could be useful for some distros who might want to make Opera more integrated.

However as I said, if the packages produced by your current automatic conversion method, then sure why not use them. There is no one right way. I was just providing an alternative. ;)

I don't see either issue myself but I would suggest you highlight these problems on the My Opera Forums, for two reasons. 1. We are now straying way off topic from the original post and I don't want to try and take over this thread and make it an Opera support thread (no point pissing off the moderators so soon after I have joined these forums). 2. There are far more Opera users on the My Opera forums and hence you will be more likely to find other users who see the same issue as you if there is a bug there and hence it will be easier to find commonalities between your and their setups that might allow us to get to the root of the problem.