Opera SLKBUILD for 13.37

[Shador]

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.

Great. As Slkbuilds are meant to be built on various systems, it's a good idea to make them as compatible as possible. You're right it doesn't matter for the final package, but it matters when rebuilding the package or even porting packages to a new architecture. You'd want to change no SLKBUILDs/SlackBuilds in that case optimally, which is highly unlikely though.
I think the SLKBUILD is now perfect. Half a second is not much that's right, but when installing 10 packages, it's already 3 minutes. But don't change it. There's no better solution with the current system as of now and I doubt there will ever be one.

[ruario]

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.

Yeah, I should probably do that rather than complaining without making any effort of my own to get this corrected.

Ok, I sent him an email.

[ruario]

Half a second is not much that's right, but when installing 10 packages, it's already 3 minutes.

3 minutes? 10*0.5 = 5 seconds unless I am missing something.

Also, not all packages need to make all three calls that I make for Opera, e.g. many would not need updated MIME information.

[Shador]

Yes, wrong numbers. I guess thinking about small values while thinking about behaviour of progressions like n²/2^n with n going towards inf, can mess things up. Guess what the sequence a_n = 0.5 * n even goes towards inf for n towards inf.
Nevermind, the performance penalty is small, I think we can agree on that and I also know that many package need none of those calls. But it's there and not so small that it's completely irrelevant. Not big enough either to pull your hairs out because of it. Nevertheless the redundany is there. But given the lack of other betters solutions, no more pulling on our hairs. .

[ruario]

Ok, thanks to everyone for the feedback.

If someone thinks it is really necessary I could submit this as a new 11.60 SLKBUILD + package right now but I figure the issues with my previous script were minor enough (and now known by a wide range of Salix developers) that this probably isn't needed right away. In which case I'll leave it this time and instead wait until a new version of Opera is released and then use this SLKBUILD as a base to repackage that before I submit it.

[gapan]

That won't be necessary.

[laprjns]

Just to add my 2 cents here (0.0153 euros). With regards to If statements in SLKBUILD, please don't forget that there is a third architecture supported in slkbuild that being ARM. I've built over 400 packages on my ARMed powered Dockstars using SLKBUILDS from the Salix repos and came across some that had If statement logic which did not account for arch=ARM. Slackbuilds also allows for the ARM architecture since I have successfully built packages using slapt-src.

BTW: Slackware ARM 'current' is now being re-based to support ARMv5te

[ruario]

Just to add my 2 cents here (0.0153 euros). With regards to If statements in SLKBUILD, please don't forget that there is a third architecture supported in slkbuild that being ARM.

Opera does not currently offer ARM versions of its desktop product.

[Shador]

Just to add my 2 cents here (0.0153 euros). With regards to If statements in SLKBUILD, please don't forget that there is a third architecture supported in slkbuild that being ARM. I've built over 400 packages on my ARMed powered Dockstars using SLKBUILDS from the Salix repos and came across some that had If statement logic which did not account for arch=ARM. Slackbuilds also allows for the ARM architecture since I have successfully built packages using slapt-src.

BTW: Slackware ARM 'current' is now being re-based to support ARMv5te

yes conditional logic on arch should be avoided in any case. It definitely breaks when adding a completely new architecture and as I mentioned previosly this should optimally mean only changes to slkbuild itself. Ultimately it's unrealistic that every Slkbuild can work without adaption. But otherwise it's usually perfectly fine to have a conditional check on libdirsuffix for example.

[ikke]

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

Guess I am that guy. Thought I was scrupulously following your instructions when building 'salt' modules. Now it is the wrong way? Could you please explain what you mean by that 'special step' and show me the right way?

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..

Did you already provide your explanation in the wiki. I seem to be unable to find it.

Thank you.