Opera SLKBUILD for 13.37

Here you can post links to your contributed packages.
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Opera SLKBUILD for 13.37

Post by ruario »

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

slkbuild -X
(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.
JRD wrote:But I think it's going a bit off topic, don't you think ?
Yep. But it gave me a chance to explain why I do things the way I do. ;)

*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.
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: Opera SLKBUILD for 13.37

Post by JRD »

I moved your post because it was really off topic of "Salix Live 13.37 rc1".
ruario wrote:Gnome from GSB
This is not Salix and not Slackware compatible either.
ruario wrote:isn't Salix supposed to be producing packages that are fully Slackware compatible?
There are
ruario wrote:In Slackware you need to make these calls yourself
Yes, but it "should not" be in the package installation process.
ruario wrote:Also having the doinst there does zero harm on a typical install
Apparently it does as the Live is none different at all from a regular install.
The problem is that by making a module, one should do a special step : use all modules in a union-fs and built the module uppon that or else it will just shadow the rest. Here the problem is the guy making the module is doing it in the wrong way, but your lines in the doinst does not follow the Salix rules of SLKBUILDs.
ruario wrote: 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. ;)
Again, no it's not "needed". It's confortable but not needed. Other Slackware distribution chose other way to update this database (on reboot, on boot, like us on package-installation, never). This IS the Slackware way of doing things, keep things simple. This is not the role of a package to maintain a cache database, but the distribution should.
ruario wrote:arch is actually defined based on uname, or this can be overridden based on what the user has defined externally
Please read the documentation about SLKBUILD, apparenntly you didn't, this is EXACTLY what SLKBUILD does, so your code is irrelevant and, like I already said, does not follow the Salix rules (that are here for a reason).
ruario wrote: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
Yes of course, again read again the SLKBUILD man page or documentation.
ruario wrote:to repackage Opera for 64-bit [..] I simply do the following:

Code: Select all

arch=x86_64 slkbuild -X
Without your adding code, it works exactly the same...for god's sake, read the manual.
ruario wrote:
So this way I can have one PKGBUILD for both architectures.
Please, don't mix PKGBUILD and SLKBUILD, the last is inspired by the first but is different.
ruario wrote:Why does it really matter if I use arch or LIBDIRSUFFIX? What difference, improvement would it make in this scenario?
Just follow package rules, it's easier to read, easier to maintain. /lib$LIBDIRSUFFIX is way simpler that doing a hazardous "if".

About doc/opera symlink, your explanation makes sense.
About spkg, I didn't know there were these differences. For "PACKAGE SIZE" maybe this should be said to the developper of spkg, maybe he's not aware of this. For the rest, I see no problem in this behavior.

And once and for all, no: packages are not supposed to maintain a distribution database (like mimetypes cache and icons cache).
Image
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

JRD wrote:I moved your post because it was really off topic of "Salix Live 13.37 rc1".
Seems reasonable. ;)
JRD wrote:Just follow package rules, it's easier to read, easier to maintain. /lib$LIBDIRSUFFIX is way simpler that doing a hazardous "if"
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.
ruario wrote:Gnome from GSB
JRD wrote:This is not Salix and not Slackware compatible either.
It is not just Gnome (that is just something I have been playing with recently where I have seen the issue), there are other desktop environments/window managers that need this as well or they will ignore the update until the user has logged out and back into their environment.
JRD wrote:Again, no it's not "needed". It's confortable but not needed. Other Slackware distribution chose other way to update this database (on reboot, on boot, like us on package-installation, never). This IS the Slackware way of doing things, keep things simple.
JRD wrote:And once and for all, no: packages are not supposed to maintain a distribution database (like mimetypes cache and icons cache).
I think maintenance is the wrong word. The package's post install isn't maintaining anything. It is just using standard calls to standard tools to prompt these caches to update to reflect the current situation. freedesktop.org provides these tools to do exactly this without having to write different methods for different environments. You can call them whenever you want or whenever is convenient. So I respectfully disagree. Indeed this is one of the reasons for having a doinst.sh.

I should also add that this is done all the time on Slackbuilds.org. Even more importantly Robby Workman, AlienBOB and even Patrick Volkerding all do this in Slackbuilds they maintain. So I would argue that this IS the correct Slackware way of doing of handling such tasks, rather than having spkg do these calls.

Here are some examples (though look around and you will see more and more of this):

Robby's xfburn SlackBuild on SlackBuilds.org (look at the linked doinst.sh).

AlienBob's VLC SlackBuild (have a search inside for doinst.sh).

Patrick Volkerding's geeqie SlackBuild for Slackware 13.37 (uncomprress and look at the doinst.sh.gz)

If Robby, AlienBob and most importantly Patrick think this is the way to do it then I would say this is the Slackware way and the correct thing to do.

P.S. I got this method from Robby as he used to maintain the Opera SlackBuild and did it the same way I am in the Opera SLKBUILD (Opera official packages do something similar but use slightly different logic).
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: Opera SLKBUILD for 13.37

Post by JRD »

Ok about being the "Slackware way" but I still thinks it's not "the right think to do".
If the distribution do it, it could do it whenever it wants. It's not at all "needed" to do it at installation. It takes a lot of time to generate such caches. If you upgrade and/or install a lot of packages, it's completely stupid to run this after each package installation. Furthermore, it is a code that doesn't need to change (same from package to package) and it's weird to duplicate it, non saying that one could bad copy/paste it.
SLKBUILDs are not slackbuilds, these are different. You should not add this to your SLKBUILD meta-script file. It's our choice to add this code at compile time while generating a slackbuild sh script (then doing the slackware way as you said), or at run time after installing the package. The same way you do not add code for handling .new files, which are generating at compile time from SLKBUILD to SlackBuild script.
Image
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Ok, I can change I but it means that the Salix Opera package is not fully Slackware compatible, at least in not my eyes. The reason I say this is because whilst Salix users will get instant updates to the mime, desktop and icons databases immediately after install, anyone who installs on real Slackware may not.

I don't want to field complaints from a user who this happens to. I have been there are done that. For a while we tried to simplify the official Opera rpm and deb files and hence these calls were removed from their post installs as well. The lack of instant update after install was one of the most frequently reported bugs at the time. We put them back to resolve the issue and because all distros do this in the post install scripts of their graphical apps (well all bar Salix apparently).

As such I'm going to stop suggesting this package (even though I maintain it) to users of actual Slackware. For them I shall start providing a different binary on my own mini repository.

If this really is the wrong way to do this, you might want to tell Andreas Born, Christian Dersch, Dimitris Jemos, George Vlahavas, Luis Henrique, Phill Watkins, Shador and Vasile Coman about this as well. Since the are all doing it in various SLKBUILDS that they maintain.

Here is a list to save you hunting down the "bad" SLKBUILDs yourself: hplip, snes9x-gtk, hatari, openttd, frozen-bubble, pitivi, evince, brasero, simple-icon-theme, thunar-thumbnailers, xfburn, lxsession-edit, disk-manager, last.fm, mkvtoolnix, hydrogen, simpleburn, bluefish, gramps, mozilla-firefox, openshot, aMule, whaawmp, epdfview, inkscape, zim, mirage, audacity, soundconverter, deluge, gsmartcontrol, frostwire, xchm, hardinfo, wbar, libreoffice, mumble, keepassx, codeblocks, fbreader, comix, flush
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: Opera SLKBUILD for 13.37

Post by gapan »

I don't see a problem with the opera package. The doinst is perfectly fine. As ruario pointed out, we used to do that a lot before I patched spkg to do that for us (which was not that long ago) and several packages have similar code. I don't see a problem with the "if" part either.

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.

ruario, about your issues with spkg, have you tried to contact the spkg developer? He is responsive to emails, it might take him a while to reply but he will do it. I wasn't aware that spkg reports PACKAGE SIZE in a different way (it what way really? I haven't checked).
Image
Image
User avatar
JRD
Salix Warrior
Posts: 950
Joined: 7. Jun 2009, 22:52
Location: Lyon, France

Re: Opera SLKBUILD for 13.37

Post by JRD »

The live module was simlpy bad created, for opera or for any other package that uses this techniques it will have behaved the same. I will explain in the wiki how to make modules for live in the proper way.
Image
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Basically the official pkgtools switch from bytes, to kilobytes, to megabytes (and perhaps one day gigabytes if we ever get packages that big) as each size boundary is hit.

spkg uses bytes and kilobytes only and even for then formats the packages bigger than a kilobyte differently to Slackware (by adding a space after file size and before the K). For example, after Opera is installed with spkg:

Code: Select all

$ head -n 4 /var/log/packages/opera-11.60-i686-1ro
PACKAGE NAME:              opera-11.60-i686-1ro
COMPRESSED PACKAGE SIZE:   11239 K
UNCOMPRESSED PACKAGE SIZE: 36608 K
PACKAGE LOCATION:          opera-11.60-i686-1ro.txz
After Opera is installed with the installpkg:

Code: Select all

$ head -n 4 /var/log/packages/opera-11.60-i686-1ro
PACKAGE NAME:     opera-11.60-i686-1ro
COMPRESSED PACKAGE SIZE:     11M
UNCOMPRESSED PACKAGE SIZE:     36M
PACKAGE LOCATION: opera-11.60-i686-1ro.txz
There are other formatting changes as well, see the tabbing. This matters for any script that expects real Slackware format. Sure, you can have a script accommodate the differences if you are aware of them but many would not be. Hence I personally think that Salix/spkg should use the same formatting for its /var/log/packages entries as the official tools, for the sake of better compatibility with upstream.

A very quick example of how this would affect me. Sometimes Slackware users talk about cutting down the install to gain space. Now the obvious response to this (and one I have used several times) is, try Salix! :P But of course not everyone accepts this or they have a genuine reason why they can't easily do this, e.g. they are using a VPS that provides Slackware proper. Usually in such scenarios I point out that they may want to consider their biggest packages first as these (obviously) give quickest result with the least effort.

I usually then provide this snippet of code, which on real Slackware would give them a list (sorted by size) of all packages over 1Mb:

Code: Select all

grep "^U.*M$" /var/log/packages/* | sed -r "s|.+/(.+):.+: +(.+)|\2\t\1|" | sort -n
This would fail on Salix for any packages that are installed via spkg because the regex ^U.*M$ won't match. Sure, I could come up with another method for Salix but it will get hairy if the user installed some of their packages with the real tools and some with spkg. Better that Salix uses a consistant formatting across installation tools.
Last edited by ruario on 20. Dec 2011, 20:12, edited 1 time in total.
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

gapan wrote:ruario, about your issues with spkg, have you tried to contact the spkg developer?
Honest answer to this question is no. I have just mumbled under my breath and said nothing to him. :oops:

Yeah, I should probably do that rather than complaining without making any effort of my own to get this corrected.
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Actually it seems that what pkgtools is doing is actually a but more subtle than that. When it switch hits 1M it uses a decimal point until it hits over 10M, then it stops using decimals.
Post Reply