Hello, everyone.

As many of you do, I guess, I update my Slackware installation with slackpkg once in a while.

What shall I do when packages get replaced with packages with different names?
(As an example, the changelog from the 2018-07-20:

)

I cannot just do slackpkg clean-system, because it would remove a lot of SBo and custom-built packages.

Maybe Patrick could add some additional lines in the changelog, like
'intel-gpu-tools-1.22-x86_6-3.txz: Replaced with igt-gpu-tools-1.23-x86_64.txz' ?

And I could bodge a patch for slackpkg to support these replacements?
Say, make an option called 'upgrade-all-replace-with-replacements-and-install-new'?

I for one, usually I will remove first the replaced package from system. I.e.
IF I consider is the case (for a package which is critical for system), I will go first the recommended way:
These package replacements are a very unusual event after all, so I do not think that is worth to complicate the slackpkg to handle that.

Anyways, these automated "replacements" you suggest are in fact a "package dependencies resolving" feature (igt-gpu-tools replaces intel-gpu-tools), and I guess that our BDFL will not like it.

See for details: http://ftp.rpm.org/max-rpm/ch-rpm-upgrade.html

Why not to blacklist SBo and your custom tags?

Well, the RPM thing is a mess. I know that according to LSB, we must actually ship rpm in any Linux distribution, but actually using it always brings more trouble than saves effort.

I don't like the idea of 'hard' dependency tracking too, because essentially it induces too much unnecessary coupling in the system. I mean, in the actual life we have dependencies between 'features', not 'packages', but since formalizing the concept of a 'feature' is too hard, it's not really worth bothering. Like, if the only 'feature' of a package you need is a man page, hell, who cares about the dependencies.

Saying that, I don't think that 'soft' dependency tracking is a bad thing. Essentially, since 'upgradepkg' already supports this tiny part of 'soft' tracking (i.e. renaming a package with a per-cent sign), why shouldn't slackpkg do that too? I mean, the package IS the same. I't just the name that changes.

Blacklist anything related to SBo in slackpkg completely?
Well, sometimes SBo packages get introduced into the main tree.

I just read it as slackpkg clean-system is used to actually clean the system from anything external. Sort of, used as a last resort in the case when 'nothing works'.

I think blacklist is the Slackware way. The slackpkg manual says:
A hint from Pat in the default blacklist file:
I use sbopkg to help keep track of extras on 14.2, there is a current version too. You might also look at slackpkg+ for more control over priority of individual packages, and repos. That's my two centavos. Have fun.

Well, I have many packages, not just sbo's.

There is no need to change anything:

• This kind of renaming only occurs in Slackware-current.
• Folks running Slackware-current are expected to read the ChangeLog before updating.
• Folks running Slackware-current are not supposed to blindly apply provided updates.
• In case of renaming, just run:
  Code:

  slackpkg install-new
  slackpkg remove <package to be removed>

2 members found this post helpful.

It's a hint, not a demand. You need to add your own ingredients, but that is a different topic I think. How To read and write regular expressions if you want to get fancy, I'm not that smart.

I can't tell you how to read, only that it is a good thing to do all over the place inside of a Slackware installation. After a decade or so it feels quite natural, and fun. I am still having fun anyway. Good luck with your request.

cheers

It also happens if you're upgrading from 14.2 to 15. And "not apply blindly" doesn't mean "do everything quick and ad-hoc". Packages are routinely replaced one with another, just as libc was replaced with glibc.

And, more importantly, in this particular case it was obvious that one package replaces another, but in general there may be no resemblance between the package names whatsoever. This may be especially annoying if there happens to be a longer list of "packages to remove".

When this will happen, you will most probably be given instructions to upgrade like those. No update is done routinely in Slackware-current, beyond the security fixes.

Again, if you carefully read the ChangeLog you will find out. If you don't and encounter issues, that doesn't mean there be a missing feature, in my opinion.

Of course you are entitled to modify slackpkg locally or script something to fit your needs. But doing such a modification upstream is another story.

Bottom line it's your machine, so nobody forbids you to use Slackware-current as it it were a stable release. But I very much doubt that Patrick Volkerding will make a change only targeting this specific use case. I could be wrong though, so good luck.

Hmm... maybe I just need to implement a 'remove-obsolete' option? Now that I'm thinking of it, maybe I don't actually need the 'replacement' information... since I can just keep track of the packages removed since the last update, and I also need to be sure that 'upgrade-all' has been run before I'm removing anything...

Blacklist those packages. That is what I would do. My custom build all have my own tags

Example:
[0-9]+cgs
[0-9]+_SBo

I don't blacklist them any more because I now use slackpkg+ to handle non-slackware packages. The only packages in Slackware (in my opinion) that should not have tags are Slackware packages all other should end with a tag.

Actually, you can, _but_ you need to deselect your SBo and custom-built packages.
This can be tedious, hence the suggestion to blacklist those packages, _but_ as the OP has pointed out, this can fail.
I have been caught by this in the past.
As I do not have a huge number of third party packages installed, my personal preference is to keep blacklisting to a minimum and live with the tedium of working through the deselection of packages when using 'slackpkg clean-system'.
The combination of 'slackpkg install-new' followed by 'slackpkg clean-system' will catch package updates with name changes, so no new functionality is needed.
As always, the ChangeLog is your friend.