JRD wrote:Oh yes, I saw your SLKBUILD and accoording to Salix packaging rules, the lines in doinst() should not be there. I don't know what's wrong but it's should not be handled by the package itself, the distribution takes care of maintaining icon and mime cache by itself.
I beg to differ. If they aren't there it does not update immediately in many desktop environments, e.g. Gnome from GSB. It may be (as someone hinted earlier in the thread) that spkg* makes the calls itself but isn't Salix supposed to be producing packages that are fully Slackware compatible? In Slackware you need to make these calls yourself. Look at the Opera SlackBuild.org script, or indeed SlackBuild scripts for most graphical applications. Also having the doinst there does zero harm on a typical install (outside of this specific case of repackaging to modules).
Now I could just not maintain packages for Salix and let Salix users get them from SlackBuilds.org but then they would receive SlackBuild script that does this in postinstall anyway (because it definitely is needed for Slackware), so nothing would actually change.
JRD wrote:By the way, other points in this SLKBUILD is not correct (arch should not be set explicitely, LIBDIRSUFFIX should be used to handle /lib|/lib64 instead of detecting architecture,
arch is actually defined based on uname, or this can be overridden based on what the user has defined externally. Personally I do it this way because this is not really a build script but a repacking script, hence you can package for either architecture (32-bit or 64-Bit) on either architecture. Or in fact on any architecture at all. Or even another OS because no 'build' actually takes place at all.
May main machine is 32-bit so to repackage Opera for 64-bit (since I am the one providing the binary packages that Salix uses) I simply do the following:
- Code: Select all
arch=x86_64 slkbuild -X
Similarly if I ever wanted to repackage the 32-bit package on 64-bit machine I could:
- Code: Select all
arch=i686 slkbuild -X
If I just want whatever is native for me right now then I can can simply run
- Code: Select all
(Which is also what most users would do).
So this way I can have one PKGBUILD for both architectures.
Why does it really matter if I use arch or LIBDIRSUFFIX? What difference, improvement would it make in this scenario?
JRD wrote:/usr/doc/opera should not be a symlink to /usr/doc/opera-version you should choose one)
Opera itself currently expects to find /usr/share/doc/opera/LICENSE. The path is hardcoded (yes, yes it shouldn't be but it is). Slackware/Salix already provides the "/usr/share/doc -> ../doc/", so a symlink from "opera -> opera-version" in doc makes this path valid.
The distribution requirements for Opera are such that the license must be shown the first time Opera is started with a clean profile. So if I don't setup that symlink Opera cannot be legally re-distributed. So yes, this is very much required. At least until I can convince someone internally (I work for Opera) to stop expecting a fixed path for /usr/share/doc/opera/LICENSE.
P.S. My other alternative would be not to move the doc directory at all but I think most would agree this is would also be incorrect. Hence I picked the lesser of two evils. The "opera -> opera-version" symlink will make zero difference to users, nobody up until now has ever even mentioned it.
Yep. But it gave me a chance to explain why I do things the way I do.JRD wrote:But I think it's going a bit off topic, don't you think ?
*I'm not actually a fan of spkg being used by default on Salix. It is fast but is the biggest cause of differences between Slackware and Salix, stretching the backwards compatible label. It apparently does stuff that should be done in the post install and it does not create Slackware valid /var/log/packages entries. The two obvious things wrong with these entries are that "PACKAGE SIZE" information is not the same format as installpkg would use (breaking any script that replies on this). Also the contents of install/ are intentionally left out meaning you can't see at a glance if the package had a doinst.sh, without also looking at /var/log/scripts. There are other issues as well but these two piss me off the most.