I am not sure if I understand your point. At first I thought you were saying that would be a con against switching to 15.0, but now I see maybe you are saying that that is a con of using -current at all, i.e. you are making the point that this is a burden that every user of -current has to face up to and can stop having to worry about by switching back to the official release?

Let's consider a specific case : libreoffice. I installed it from slackbuilds about 18 months ago (while on -current). I have upgraded -current many times since then and I can see that theoretically on each upgrade libreoffice might stop working and need to be rebuilt. BUT --- (correct me if wrong) slackbuilds does not recognize existence of -current - it asks me which official release I am on. checking just now, the libreoffice on slackbuilds is still the same one, and the relevant official release is still 14.2. Yet my slackware environment is now (presumably) much closer to 15.0 than it is to 14.2. As it happens, I have never rebuilt libreoffice and it still works. If it ain't broke ...

I suppose what you have got me wondering is, on that slackbuilds page for selecting the package, what is the significance of the selection I make in the dropdown letting me specify the official slackware release? It it has much significance at all, then I would not expect my existing libreoffice to work at all. And if it did break, I would probably be inclined to go fetch a whole new libreoffice package from
libreoffice.org, as the one from slackbuilds is 6.2.8.2 and the current one from libreoffice.org is 7.2.4.

Apologies for this comment getting rather confused - I'm unable to un-confuse it.

1 members found this post helpful.

On -current, there may (will at times) be library .soname changes that cause software to need recompiling, or upgrading/patching if it won't compile.

There's often some help with that from alienbob though

https://alien.slackbook.org/blog/

For example you could get scripts to build things, binary packages for Libreoffice (currently 7.2.3 for -current), compat packages for boost and icu4c when they get broken etc.

On the updates to stable edition of Slackware, soname changes are unlikely and mass rebuilds of packages aren't going to happen.

2 members found this post helpful.

How complicated is it to upgrade from a stable version to the current version?

I've been running current on my laptop since I bought it (for the usual reasons - needed the newer kernel for hardware support, wanted the newer gcc and cmake, etc). I've done lots of Slackware version upgrades (14.0 -> 14.1 -> 14.2) in the past on other machines, with zero problems, but this is the first time I've run current.

I'm thinking that I might switch from current to 15.0 when it comes out. But let's say I decide in year or two that I want to go back to current (for whatever reason). Will that be similar to a stable-to-stable update (like 14.2 -> 15.0), or will it be more difficult?

I highly recommend this

https://www.linuxquestions.org/quest...1/#post6147728

It's what I followed when I moved from 14.2 to -current

Caveat: It *might* be slightly different from 15.0 to -current, but I don't see anything other than obviously the actual reference to 14.2

1 members found this post helpful.

Maybe I'm wrong, but since Slackware 15.0 will just be a freeze of the actual -current (and not an upgrade)
For me, it's just a matter of the url in the slackpkg mirror

vs.
note:
"from 15.0 to -current" doesn't mean anything to me
I took the liberty of thinking that you meant the opposite ;-)

1 members found this post helpful.

John Lumby: Thanks, that looks like exactly what I would need.

marav: Nope, I actually meant 15.0 to current. It was a hypothetical question about the future. At some point, after 15.0 is out, if I wanted to switch from 15.0 back to current, what is the process? I think John's link answers that question. Of course, my question is purely hypothetical until 15.0 has been out for a while :-)

That's exactly correct. When Slackware 15.0 is released there will be a period of time where Slackware 15.0 and Slackware64-current are identical. So within that window you can change your mirror from Slackware64-current to Slackware 15.0.

1 members found this post helpful.

Will there be some way (other than running diffs etc) of knowing
a) when that window is about to end
b) whether the window has in fact ended

Don't put the cart before the horse

Mr. Volkerding has in the past taken a brief break from his development duties after a stable release. There's no way to know how long that period of time will be. It might be days or a few weeks or he may continue with development. To find out if development has started you can read the Slackware-current changelogs. You can also run slackpkg.

1 members found this post helpful.

Simple. I've been doing this since 2010. That is the year I switched to current, been there ever since.

If you update current with the release, that is the set time you are at the release version. That window ends with the next current update.

If you do not want to stay with current, then don't update anymore until you switch to the release mirror.

Example with 14.2 release for Slackware64-current:
At this point the current was the same as the release version. If I had wanted to switch over to 14.2, this is the point I would have changed my mirror to 14.2 vice current.

At this point it was no longer release, but now current for the next release, in this case the first current update leading to the long awaited 15.0 release.

2 members found this post helpful.

My $0.02 ( for what it's worth )

If you manage updates manually like I do and you swap from Current to 15.0 then you'll find your updates under the /path/to/patches/ Directory rather than under /path/to/slackware64/ ( or /path/to/slackware/ )

The /path/to/patches/ directory contains two directories: packages/ and source/

The packages/ directory is 'flat' -- each updated package will be here as a .txt, txz and txz.asc file.

The only exception in 14.2 is that Kernels are stored in a versioned directory. Example: the latest Kernel Files are in patches/packages/linux-4.4.276/

The source/ Directory includes a subdirectory for each updated package where the SlackBuild, install.sh, Source Code and Patches are stored.

Pretty simple for me because I keep a local mirror via rsync and I simply upgradepkg --installnew each new .txz from /path/to/packages/ for all but the kernel.

I install each Kernel so I have a fallback in case of screw-up on my part

-- kjh

2 members found this post helpful.

Yeah, recompiling software isn't something you have to worry about on static release distributions all that much until the next release. I remember my time on arch linux was spent having to recompile AUR packages and local software that I compiled every couple of months thanks to the rolling model. So in summary, that's a con for staying on current.

1 members found this post helpful.

When I run slackpkg check-updates, it checks against my local mirror, (because that's what my /etc/slackpkg/mirrors points to), which is not what I want in this case (as I don't run my mirror-slackware-current.sh every day). I realize I could temporarily modify my /etc/slackpkg/mirrors to point to a remote bang-up-to-date mirror, but is there a slackpkg command-line OPTION I can specify to tell it which mirror to ask? the man page for slackpkg seems to suggest it might be possible but I don't see how.

I guess it is really easier to go check on the slackware ftp site.

this will temporarily override your configured mirror

3 members found this post helpful.