I've built a few custom packages using the packaging naming convention:

Slackpkg still wants to upgrade them to older releases.

Attached Thumbnails

 

That is expected behaviour. If it concerns you, add a modified tag to your custom builds and add that to your /etc/slackpkg/blacklist.

1 members found this post helpful.

happens to me all of the time.
I just black list the other one.

2 members found this post helpful.

If I blacklist with a modifier tag then will the package be blacklisted indefinitely or will slackpkg still upgrade when there is a new major release?

The package will be blacklisted indefinitely. It can be trap, which I have fallen into myself. I had a package from SBo installed. That package then entered Slackware, but was not handled by slackpkg because I had blacklisted all my SBo packages.

1 members found this post helpful.

if you remember that it is blacklisted when and if that happens all you have to do is manauly open the file that keeps the names of blacklisted stuff and remove it from that list then you're back to square one, or bobs your uncle.

With a handful of modified packages that might be a reasonable thing to do. It could become difficult remembering which packages were customized. The second problem is that slackpkg doesn't tell in advance whether the upstream packages from the repository are new or not.

that is why it is called package management. If I were to upgrade every major package in Slackware just so I could have the updated version to the point that I have more than say maybe five packages that Slack has. I'd look for a rolling release ( independent ) distro. So I could have the latest and greatest. and leave Slack alone.

As it stands I do have a tri-boot and what I have upgraded in Slack is not something that Slack I'd think Slack would update anyways, WMaker. and something else.

So yes you're going to run into issues if you take a system that is set up to be as it is until its next major upgrade and do incremental updates to parts of it, and expecting it to run smoothly every time you run slackpkg update.

SO more special care will be needed to maintain your Slack Box if one goes to fiddling with it too much.

if one installs slackpkg+ you can put the packages to the greylist instead of the blacklist. Then, upgrade-all dialog will display them but they will un-checked. As you iterate over all the packages displayed like that, you will be informed which package is installed and which package is available to replace it. Sort of the best of both worlds. These days, the only thing I have in blacklist is keepassx, because upstream decided to "upgrade" its database format, and I preferred not to do that so I could share it with an Android app I use.

I specify the all the kernel packages in the greylist, too. It keeps me from doing anything there by accident, but tells me what's available.

1 members found this post helpful.