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).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.
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.
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.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,
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
Code: Select all
arch=i686 slkbuild -X
Code: Select all
slkbuild -X
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?
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.JRD wrote:/usr/doc/opera should not be a symlink to /usr/doc/opera-version you should choose one)
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.