I see, you've agreed to change this. I still want to say something about this. As you may have a software development background yourself, you probably know that it's a lot more convenient and much better design to avoid redundancy and copy and past code and that's the whole idea of SLKBUILD. The same goes for LIBDIRSUFFIX. It's everytime the same code to determine the right suffix. But now imagine every package copied that code and somebody decided to port Slackware to another arch or do some other change. He would have to change each and every package. When using LIBDIRSUFFIX, all that needs to be changeled is the slkbuild tool itself, which is much more convenient and reliable.ruario wrote:Ok, I will update the SLKBUILD to use /lib$LIBDIRSUFFIX. It is no easier for me to read or maintain but I'll grant you that it makes more sense to those who have worked with other SLKBUILD/SlackBuild scripts so I will change to better align with what other packages are doing.
I still need an "if" however as the mv and sed correction commands only need to happen "if" $LIBDIRSUFFIX is 64, otherwise they are not needed. I would love to do it without as is typically done in source packages but the Opera install script does not provide any way to define the lib directory. So I will just be using $LIBDIRSUFFIX instead of $arch but otherwise the logic will be pretty much the same. Remember this is a binary repackage, not a regular source based package. Hence some things will have to deviate slightly but I will use $LIBDIRSUFFIX to keep the differences as minimal as possible.
Unfortunately there are other aspects of Slackware that have such redundancies, which are imho regardless where they appear quite inconvenient. This is heritage for such an old distribution, I guess, but makes me feel somewhat uncomfortable. SLKBUILD has some problems like that too, especially in some special use cases, I've hit recently. But another good example is the cache update in the doinst. Again redundant code, which even affects performance here. Obviously, it's not optimal either to update those caches after any package operation, by some shared utility like spkg. But still better regarding performance and reduncancy than the latter. But I've come to the impression that there are parts, where Slackware/Patrick is unwilling to improve, to go with new developments (and we're not talking about super-fresh hypes here). IMHO this is very unfortunate and sad.
The problem is that the package is installed in a subdirectory including the package caches. But in that subdirectory the package caches of course only reflect the packages installed in that subdirectory. The module just contains the content of that subdirectory. The Live CD just overlays the all modules with custom ones taking highest precedence, which is necessary and what you want when talking about custom. Unfortunately the cache files from the opera module overlay those of all other modules. So the resulting cache file only contains data for the files of the opera package. All other cache information is dumped. This can't be really changed from the Live CD. As JRD pointed out, it's a matter of building the modules properly.gapan wrote:If there is a problem with creating a live module out of such packages, maybe we should examine why it is a problem with live modules and try to fix that instead.