How does /testing get enabled for -current?

You will need to upgrade the packages under testing manually

What do you mean?

Do you want to install the testing packages?

If so, you can do it using upgradepkg.

Download them and upgradepkg them.

This was covered in the other thread. I'm not sure why you felt a need to start another topic on it.

1 members found this post helpful.

There seems to be an issue with slackpkg and slackpkg+. slackpkg doesn't pickup /testing but slackpkg+ does.

There's this in the conf file:
PRIORITY=( patches %PKGMAIN extra pasture testing )

But slackpkg does not seem to use that setting or I misunderstand it. But slackpkg+ does use that.

So -current with slackpkg+ is not that same as -current with slackpkg.

Or use slackpkg+ as it seems to pickup /testing automatically.

slackpkg is not supposed to pick up testing/

testing/ can contain packages that replace the system packages (since packages in testing/ are able to sometimes replace system packages). Slackpkg doesn't handle that, it will only see a package and check whether it needs to be installed. It doesn't have anything to determine whether you should install one version or another. You need to use slackpkg+ for that.

Why would you want that?

/testing is hardly used, but when it is you can bet that there's something "structural" in there. i.e: There is a high probability that it will break your system, which is why it is sequestered.

Why is PRIORITY=( patches %PKGMAIN extra pasture testing ) set in slackpkg conf?

It's a slackpkg+ feature. I don't know about the choices they made when they wrote slackpkg+, so you'd have to ask them "Why?".

you don't need slackpkg+ if you want /testing to have an higher precedence when using slackpkg.

you just have to change the line you noted above in /etc/slackpkg/slackpkg.conf like this
doing this on current, after you installed the newer gcc, will result in a lot of things from SBo stop building (I think this will also happen if you will try rebuilding stuff in Slackware itself): be aware (and advised) that you might not get support for thi building errors because if you use the testing stuff it's supposed that you know how to fix things yourself.

It turns out the package I was searching for on 14.2 was spelled wrong on the server. kernel-module-encryptfs is actually missing the n on encryptfs (kernel-module-ecryptfs is on the server), so when I attempted to find it using the right spelling, nothing showed. That led me to believe that testing/ was not supported by slackpkg.

However, after spelling it the way it is on the server, it does allow me to install from testing/. Sorry for the misinformation there.

Now that I've cleared up my own confusion, the only way to "set up" testing/ with slackpkg (for packages that already exist in Slackware -- new packages should be able to be installed using slackpkg install package-name) is to change the PRIORITY variable in the slackpkg.conf file and put testing before %PKGMAIN. The issue with this is, as far as I know, there is no way to specify which packages you want from testing and what you'd want from Slackware proper. So, if you were to change this variable, you'd get all new gcc stuff, as well as efibootmgr-0.6.0 (vs -current's 0.5.0) right now in -current. That might not be a big deal now (especially if you aren't using efibootmgr), but if Pat puts something big in testing/ and you aren't paying attention, you might suddenly end up with a system that doesn't work the way you expect it to. A prime example of this is when Pat added eudev to testing/. He provided a list of software that would likely have problems unless you recompiled them after installing eudev. If you happened to miss that message, your system could've been unbootable or been very broken when it does boot up.

It's obviously up to you on how you want to handle it, but due to the unknowns, personally, if you feel inclined to install stuff from testing/, I would install those packages manually and then blacklist them. Then you'd just need to keep an eye on the changelog to see if Pat updates any of them. This prevents your system from getting borked if something is added and you don't realize the repercussions. But, I haven't felt a need to use testing/ since Slackware 11.0, when he had the 2.6 kernel available in testing/ with the 2.4 kernel in proper, so it's been almost a decade since I've done it.

1 members found this post helpful.

The big surprise to me and apparently others is that there are actually three different native slackwares.
Stable, -current and testing. It was something I didn't know about. Plus along the way I discovered that slackpkg+ includes /testing automatically using the same PRIORITIES used by slackpkg. Maybe a feature but it was unexpected behavior.

I don't understand why you got that impression.
it seems to me that we explained multiple times that there's just Slackware stable and slackware-current, the development version (*not* a rolling release), and that /testing is just a directory in the the distribution tree: the fact that you can easily install packages from that directory via slackpkg doesn't actually mean anything, it's just a commodity offered by slackpkg, it doesn't mean that "testing" is another version of Slackware.

3 members found this post helpful.