Opera SLKBUILD for 13.37

Here you can post links to your contributed packages.
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Opera SLKBUILD for 13.37

Post by Shador »

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.
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.
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. :(
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.
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.
Image
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

ruario wrote:arch is actually defined based on uname, or this can be overridden based on what the user has defined externally
JRD wrote: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).
I had already read the documentation, though I couldn't remember my exact reasoning for doing it this way. Now having tested again I remember. It is not exactly the same. My way means that arch is defined immediately before the build section and hence I can use it right away to define _oarch, which I need to be select the right source. If I don't define the arch in the SLKBUILD then it is not available to me until the build section, which means _oarch is undefined and hence the right source package is not selected.

This probably isn't generally a problem for others because they are using actual source packages, which would not have an architecture in their name. So once again this is a difference that I introduced (like some of the other things you picked up on) as this is a binary repack that cannot exactly follow the normal steps, rather than an actual build.

Do you have another way around this, or can I continue to use my current method?

P.S. It may not be a long SLKBUILD but I did spend a fair amount of time considering it when I wrote it. It wasn't just quickly hacked together with total disregard to anything else as you appear to think. Hence why some of my answers may have appeared a little over defensive.
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Opera SLKBUILD for 13.37

Post by Shador »

Yes thatMs exyctly one of the problems I was hiting myself. Here it was the binary version of a compiler needed to bootstrap the compiler. I did it similarly as you. But barely copied the code from SLKBUILD, that sets this code. Recently I investigated this issue a bit and came to the conclusion that seeting arch earlier in Slkbuild woulb be a much beeter solution. Slkbuild couldn't tell anymore whether it's choice is overwritten, but that's not important anyway imo. Didn't get round to it though.

Regarding your Slkbuild, I don't think it sets arch properly when specifying nothing on ix86. arch remains set to the value of uname -m i.e. ix86 and only _oarch seems to be set to i386. Slkbuild only overwites arch if nothing is specified, so that's wrong, unless you intentionally want i686 or sth else than i386 anyway. I don't think so.

Your effort maintaining opera is recognized by everybody, I think. Although I don't use it myself. Without reasoning some of your decisions may seem unnecessary. So it probably seems quite harsh when starting to pull your Slkbuild appart. ;)
Image
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Shador wrote:Regarding your Slkbuild, I don't think it sets arch properly when specifying nothing on ix86. arch remains set to the value of uname -m i.e. ix86 and only _oarch seems to be set to i386. Slkbuild only overwites arch if nothing is specified, so that's wrong, unless you intentionally want i686 or sth else than i386 anyway. I don't think so.
Actually I do want the Slackware/Salix Opera package that is created to be labelled i686 because in fact it is an i686 package, not an i386 package. ;)
Shador wrote:Without reasoning some of your decisions may seem unnecessary.
My biggest takeaway from this is this SLKBUILD needs more commenting, to better explain why things are being done. ;)
User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

Re: Opera SLKBUILD for 13.37

Post by thenktor »

ruario wrote: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 think a lot of Slackware's official packages update any database after installation.
gapan wrote: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.
I agree. Furthermore I had an "if" part in my own SLKBUILD, too :)
ruario wrote: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.
If you really want to strip down an installation you have to know what you are doing. Looking for the big packages first may seem to be a good idea, but in the end quite useless.
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)
Shador
Posts: 1295
Joined: 11. Jun 2009, 14:04
Location: Bavaria

Re: Opera SLKBUILD for 13.37

Post by Shador »

ruario wrote:Actually I do want the Slackware/Salix Opera package that is created to be labelled i686 because in fact it is an i686 package, not an i386 package. ;)
ok, so it's actually mislabeled by opera. Anyway ypu should make sure then that arch is set to i686. As uname -m can output also different values on certain system (eg i3/486), as far as I know.
thenktor wrote:I agree. Furthermore I had an "if" part in my own SLKBUILD, too :)
if is no problem. I think JRD's point was that LIBDIRSUFFIX is cleaner and he assumed it makes the if unnecessary too, which is not a bad thing either.
Image
User avatar
thenktor
Salix Wizard
Posts: 2426
Joined: 6. Jun 2009, 14:47
Location: Franconia
Contact:

Re: Opera SLKBUILD for 13.37

Post by thenktor »

Shador wrote:if is no problem. I think JRD's point was that LIBDIRSUFFIX is cleaner and he assumed it makes the if unnecessary too, which is not a bad thing either.
I've even used LIBDIRSUFFIX for my "if" statement :)

Code: Select all

# fix lib location for x86_64 systems
        if [ ! -z $LIBDIRSUFFIX ]; then
                mv $startdir/pkg/usr/lib $startdir/pkg/usr/lib$LIBDIRSUFFIX
                sed -i s#/usr/lib/#/usr/lib$LIBDIRSUFFIX/#g $startdir/pkg/usr/bin/opera*
        fi
Image
burnCDDA (burns audio CDs)
geBIERt (German beer blog)
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

thenktor wrote:I don't think a lot of Slackware's official packages update any database after installation.
All of the following official packages make these types of calls: akonadi-1.4.1-i486-3, amarok-2.4.0-i486-1, audacious-2.4.4-i486-1, blueman-r708-i486-1, djvulibre-3.5.24-i486-1, geeqie-1.0-i486-3, gpa-0.7.5-i486-1, hplip-3.11.3a-i486-1, k3b-2.0.2-i486-2, kaudiocreator-r1212483-i486-1, kdeaccessibility-4.5.5-i486-1, kdeadmin-4.5.5-i486-2, kdeartwork-4.5.5-i486-2, kdebase-4.5.5-i486-3, kdebase-runtime-4.5.5-i486-2, kdebase-workspace-4.5.5-i486-1, kdeedu-4.5.5-i486-1, kdegames-4.5.5-i486-1, kdegraphics-4.5.5-i486-3, kdelibs-4.5.5-i486-2, kdelibs-4.5.5-i486-2, kdemultimedia-4.5.5-i486-1, kdenetwork-4.5.5-i486-1, kdepim-4.4.10-i486-1, kdepim-runtime-4.4.10-i486-1, kdeplasma-addons-4.5.5-i486-1, kdesdk-4.5.5-i486-1, kdetoys-4.5.5-i486-1, kdeutils-4.5.5-i486-1, kdevelop-4.2.2-i486-1, kdevplatform-1.2.2-i486-1, kdewebdev-4.5.5-i486-1, koffice-2.3.3-i486-2, kopete-cryptography-1.3.0_kde4.4.0-i486-1, ktorrent-4.0.5-i486-1, skanlite-0.7-i486-1, system-config-printer-1.2.7-i486-1, xfce4-notifyd-0.1.1-i486-1, xfce4-power-manager-0.8.5-i486-1 and xpdf-3.02pl6-i486-3.

There may be more but those are ones I have checked. Many of the graphical applications that do not currently make these types of calls are clearly using fairly old build scripts that have not been updated in a while. So I would say the trend is actually for more and more of official Slackware packages to do this in the future.
thenktor wrote:If you really want to strip down an installation you have to know what you are doing. Looking for the big packages first may seem to be a good idea, but in the end quite useless.
That is not entirely true. Sure it is better to be more selective and if you are going to do that Salix is an easier option but you can reduce the install size quite quickly by looking at the biggest packages first and considering if you need them, for example:
  • All of the KDE series for a 900Mb saving
  • kernel-source package 415Mb (installed size). Whilst you will need this package if you want to compile a custom kernel or if you need to compile special kernel modules (like the VitualBox Guest additions), it can be a nice saving if you don't need it. Even if you do need it you can still consider removing after you are finished with it, as it is the type of package you are most likely to want only at the beginning, when first setting up your system.
  • All of the t series for a 250Mb saving
  • Qt another 129Mb (worth it if you aren't using KDE or other Qt based apps)
  • Samba for a 125Mb saving
  • Emacs 90Mb or Vim 26Mb (or both!)
  • Either kernel-modules or kernel-modules-smp as you probably don't need both. The are just over 70Mb each.
  • Seamonkey 66Mb or Firefox 32Mb (or both and install Opera at 34Mb, which could also replace the 30Mb Thunderbird)
  • Gimp 54Mb
It isn't a perfect method, nor did I claim it to be but all of the above are fairly easy choices for the average user to make and allow them to take large chunks out of the install size with relatively little effort.
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Shador wrote:ok, so it's actually mislabeled by opera. Anyway ypu should make sure then that arch is set to i686. As uname -m can output also different values on certain system (eg i3/486), as far as I know.
Yes but will it really matter or make any difference to installation?

By the way, I have updated my own copy of the Opera SLKBUILD to use $LIBDIRSUFFIX and added liberal comments throughout to better explain some of the seemingly odd things I am doing.

As you will see, I have left the doinst in place for now (but with better commenting) as I would still rather produce a package that works as expected on actual Slackware, in addition to Salix.

I know there is some concern about the performance penalty of leaving my doinst in place and the redundancy of it. So I decided to check how long it takes and what is actually happening. I therefore created two test packages, one with the doinst (opera-11.60-i686-2ro.txz) and one without (opera-11.60-i686-3ro.txz) and then time installation. This is actually being done on my own 32-bit Slackware 13.37 installation. It is a full install with extra packages from Slackbuilds.org, AlienBoB, Salix, etc. so it should have fairly large application, icon and mime caches.

With doinst

Code: Select all

# time spkg -i opera-11.60-i686-2ro.txz
Installing package opera-11.60-i686-2ro...
| opera (Fast and secure web browser and Internet suite)
| 
| Opera is a small, fast, customizable, powerful and user-friendly web
| browser, as well as an Internet suite, including an email client, an
| IRC client, web developer tools (Opera Dragonfly), and a personal web
| server (Opera Unite).
|  
| http://www.opera.com/browser/
| 
| 
| 
| 
| 

real    0m5.542s
user    0m3.259s
sys     0m0.621s
Without doinst

Code: Select all

# time spkg -i opera-11.60-i686-3ro.txz
Installing package opera-11.60-i686-3ro...
| opera (Fast and secure web browser and Internet suite)
| 
| Opera is a small, fast, customizable, powerful and user-friendly web
| browser, as well as an Internet suite, including an email client, an
| IRC client, web developer tools (Opera Dragonfly), and a personal web
| server (Opera Unite).
|  
| http://www.opera.com/browser/
| 
| 
| 
| 
| 

real    0m4.982s
user    0m2.820s
sys     0m0.542s
So as you can see the difference is about half a second.

I should also add that running an strace on the install of "opera-11.60-i686-3ro.txz" I can see that spkg does not make the calls to update-desktop-database or update-mime-database at all. Only to gtk-update-icon-cache. So for full integration after install in all possible desktop environments the doinst is needed anyway.

Code: Select all

# strace spkg -i opera-11.60-i686-3ro.txz 2>&1 | fgrep -e update-desktop-database -e update-mime-database -e gtk-update-icon-cache
access("/usr/bin/gtk-update-icon-cache", X_OK) = 0
ruario
Posts: 88
Joined: 23. Dec 2010, 08:41

Re: Opera SLKBUILD for 13.37

Post by ruario »

Shador wrote:ok, so it's actually mislabeled by opera. Anyway ypu should make sure then that arch is set to i686. As uname -m can output also different values on certain system (eg i3/486), as far as I know.
Ok, it is a bit of a hack job but I am accounting for this now, see my personal Opera SLKBUILD. I didn't bump the pkgrel this time, so reload if you think you have looked at it already. ;)
Post Reply