OK, I shouldn't have said never, in the worst case they would have to wait about a year (ESRs are released annually). In the case of better hardware video decoding support, which was added with Firefox 24, this would mean that users with older hardware would have to wait that long for getting better performance. The best option of course would be to have both versions available, one in the normal tree, one in /extra.

It is not especially hard to repack the binary builds that Mozilla produces (I do it), so if you don't want ESR you don't have to use it. If you do repack rather than recompile the KDE/FF bug does not appear.

As far as I know the KDE/FF bug only appeared in 14.0, but not in -current, so this shouldn't be a problem anyway. The problem with repacking the binaries is that they are, AFAIK, not compiled with PGO, which means they come with sub-standard performance.

two small clarifications:
- the bug actually is between oxygen-gtk2 (the default gtk theme under kde) and firefox >= 22.0 on slackware64-14.0 (14.0 32bit and current/14.1 are not affected): it manifests also under xfce if you use the oxygen-gtk2 theme with it (firefox segfaults);
- the binaries from mozilla are, AFAIK, built with PGO.

the Mozilla binaries use PGO.

actually it is the Slackware binaries that are not compiled with PGO. from http://ftp.uninett.no/pub/linux/slac...fox.SlackBuild

To use the non-ESR version of firefox I distilled the infrastructure from the xap/mozilla-firefox-24.0esr-x86_64-1.txz package into the attached package (rename .txt to .txz), the slack-desc of which reads:Download the firefox-24.0.tar.bz2 file, removepkg mozilla-firefox (your settings and addons are preserved), installpkg mozilla-firefox-infra and untar the tar.bz2 file. You should now be able to start firefox as usual.
Note that to install a new firefox version you just have to replace the /usr/lib64/firefox directory.
Note too that the .tar.bz2 can also be a localized one.
:D

here, I'll make even easier. run this:
www.panix.com/~ruari/latest-firefox

Ok, I stand corrected on that, I remembered it the other way around.

Thanks for that.

Just a nitpick: Slackpkg and friends will want to replace that latest firefox with the package in the repository. You should name your package mozilla-firefox-latest or something like that.
:D

/etc/slackpkg/blacklist is your friend :)

Exactly! ;)

Of course blacklisting the package will stop it from being overwritten by the repo version. But why requiring an additional action (the blacklisting) instead of a simple change (change the package name) to the script?
:D

Because that is the entire point of blacklisting, to allow you to prevent slackpkg from manipulating packages you don't want it to touch. Blacklisting is already in wide use in the Slackware community. Why make a new system based on obscure naming, which seems flawed. Off the top of my head:

• How do I easily get my system back to having only original versions of standard packages (with blacklisting I can just wipe blacklist and upgrade-all)?
• How am I supposed to remember the various obscure names if I start doing this a lot (in the case of blacklisting I need only look in/edit one file should I need to change anything)?
• If Slackware proper ever uses my package name convention my custom package would get wiped anyway.

I'm not planning on changing my script in this regard but if you would like to use it and decide you would prefer go down the nonstandard name route by all means edit it locally. ;)

OK, let us agree to disagree then.
Kind regards, Dick :D