LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackpkg 'replace-with-substibutes' suggestion (https://www.linuxquestions.org/questions/slackware-14/slackpkg-replace-with-substibutes-suggestion-4175634580/)

Lockywolf 07-20-2018 11:22 PM

Slackpkg 'replace-with-substibutes' suggestion
 
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:

Code:

x/igt-gpu-tools-1.23-x86_64-1.txz:  Added.
x/intel-gpu-tools-1.22-x86_64-3.txz:  Removed.

)

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'?

Darth Vader 07-20-2018 11:39 PM

Quote:

Originally Posted by Lockywolf (Post 5881877)
What shall I do when packages get replaced with packages with different names?

I for one, usually I will remove first the replaced package from system. I.e.
Code:

removepkg intel-gpu-tools
IF I consider is the case (for a package which is critical for system), I will go first the recommended way:
Code:

upgradepkg intel-gpu-tools%igt-gpu-tools-1.23-x86_64-1.txz
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

bormant 07-21-2018 12:06 AM

Quote:

Originally Posted by Lockywolf (Post 5881877)
I cannot just do slackpkg clean-system, because it would remove a lot of SBo and custom-built packages.

Why not to blacklist SBo and your custom tags?

Lockywolf 07-21-2018 12:07 AM

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.

Lockywolf 07-21-2018 12:15 AM

Quote:

Originally Posted by bormant (Post 5881886)
Why not to blacklist SBo and your custom tags?

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'.

EYo 07-21-2018 05:14 AM

Quote:

Originally Posted by Lockywolf (Post 5881888)
Blacklist anything related to SBo in slackpkg completely?

I think blacklist is the Slackware way. The slackpkg manual says:
Quote:

clean-system
This action removes all of the packages that don't belong to a standard Slackware installation. With this option, you can clean up your system, removing third-party packages as well as any packages that were removed from the official Slackware package set.

If you have some third party (or custom built) packages that you would like to keep, you can temporarily add them to the list of blacklisted packages before you run the 'clean-system' action.
A hint from Pat in the default blacklist file:
Quote:

# This one will blacklist all SBo packages:
#[0-9]+_SBo
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.

Lockywolf 07-21-2018 05:24 AM

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

Didier Spaier 07-21-2018 05:33 AM

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>


EYo 07-21-2018 05:35 AM

Quote:

Originally Posted by Lockywolf (Post 5881946)
Well, I have many packages, not just sbo's.

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

Lockywolf 07-21-2018 07:05 AM

Quote:

Originally Posted by Didier Spaier (Post 5881948)
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>


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".

Didier Spaier 07-21-2018 07:29 AM

Quote:

Originally Posted by Lockywolf (Post 5881971)
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"

When this will happen, you will most probably be given instructions to upgrade like those.
Quote:

Packages are routinely replaced one with another, just as libc was replaced with glibc.
No update is done routinely in Slackware-current, beyond the security fixes.

Quote:

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".
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.

Lockywolf 07-21-2018 07:59 AM

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...

chrisretusn 07-21-2018 10:29 AM

Quote:

Originally Posted by Lockywolf (Post 5881877)
I cannot just do slackpkg clean-system, because it would remove a lot of SBo and custom-built packages.

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.

allend 07-21-2018 12:56 PM

Quote:

I cannot just do slackpkg clean-system, because it would remove a lot of SBo and custom-built packages.
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.
Quote:

Well, sometimes SBo packages get introduced into the main tree.
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.


All times are GMT -5. The time now is 02:56 PM.