Slackware-current 64 bit, pure-alsa, how to manage updates for pure-alsa-system?
 

Hi, I today blindly ran slackpkg and rolled-back to broken non-alsa pulseaudio. KDE refused to start. From now on slackpkg always will be listing default packages in slackware64 as updates. So it seems I need a combination of blacklist and probably script to verify sanity of pure-alsa after update. Help appreciated.

I don't use slackpkg, but as the /pure-alsa-system directory is inside /extra in the Slackware tree I assume that you should change this line in /etc/slackpkg/slackpkg.conf:
PRIORITY=( patches %PKGMAIN extra pasture testing )

So that it becomes:
PRIORITY=( patches extra %PKGMAIN pasture testing )

Then:
slackpkg update
slackpkg upgrade all

I am not running Slackware64-current so can't check: take your risks.

As an aside, blindly doing things is never recommended, even more so with Slackware64-current.

The risk there however is that it could pull in something else from extra/ that you didn't particularly want.


I don't use slackpkg either, I use my own scripts which can handle this sort of thing, but they're designed to work with a local package mirror (updated with rsync or some such) so they're of no use to anyone who just wants to pull individual updates over the network. I consider 2GB for a local package mirror well spent and wouldn't do it any other way, but I accept it's not for everyone.


BTW, unless you're using some really brain dead application that refuses to fall back to ALSA when pulse isn't running you don't really need these alternative packages in order to disable pulseaudio. It can all be done via configuration changes.

I don't use pure alsa on this computer but i think i used "extra:.*_alsa" on one i used it on with slackpkg+.
I had it first under PKGS_PRIORITY=

That's the modification that I used on my pure alsa system. That prevented slackpkg from over-writing the pure alsa packages and breaking KDE apps. Please see this thread on this topic.

https://www.linuxquestions.org/quest...em-4175639807/

GAZL, I appreciate your observation about pulling in other packages from extra. I didn't see that happen in my use case.

I guess it would depend on whether there are ever any additional 'alternative' packages in extra/ that might replace some other stock packages. I raise it only as a possibility and something to watch out for. I'm not suggesting it will cause a problem as things stand.

My own scripts just work on directories rather than some notion of predefined "repositories", which, though primitive, allows a lot of flexibility.
e.g.
I've been using this to follow current for around 5 years now. It works for me, but as I said above, not everyone wants to keep local package mirrors.

Agreed. I'm no longer using the pure-alsa-system. I've moved that unit to OpenBSD 6.4.

There's a lot to like about it, I have 6.4 triple booting with Slackware and Win10 (needed for hardware diagnostics and firmware updates that my vendor only provides for Windows).

Sadly utf8 support is still lacking in many of the utilities in OpenBSD base and the c library's regex engine.

Nice! I'm dual booting Slackware and OpenBSD on another unit. How do you manage the triple boot, that is, do you have Windows on its own hard drive?

Watch your words, people!

The inventor of those Anti-Cancer Candies (if you permit me to borrow the Darth Vader's words from somewhere) looks being a champion on shooting from your back. Apparently, he's a specialist on reporting campaigns. Remember Darth's and a4z stories and remember who's behind that pure-alsa-system business.

I miss Darth!
:)

Thanks for the warning, mate! As a retired educator I have a lot of time on my hands and I do like to tinker with my PCs. Me moving from a pure-alsa-system to OpenBSD should not be taken as a criticism of the pure-alsa-system.
People are free to say anything they want. I have no control over what people say and do. I do appreciate your concern, LuckyCyborg. :)

All on the same drive. I just copied OpenBSD's bootx64.efi file to /boot/efi/EFI/OpenBSD/ and then used slackware's efibootmgr utility to add an extra bootmenu entry.
Boot0001 is Windows
Boot0002 is Slackware
Boot0003 is OpenBSD.

I just have to press f9 while booting and pick one.

I suppose small patch to slackpkg config is in place. Or word of explanation in extra/pure-alsa-system/README. Solution at hand. With help obtained here I can manage create package management myself, and suppose quite complex - but that's not the point. Point is to avoid holes in what is supposed to be nicely working operational system - from the start. Just follow simple rules. At this moment it is not. Problem is that extra was extra - out of default packages. Life was easier. Now there is intersection with defaults. Probably one of possible solution is to add priorities to slackpkg. If in doubt - follow higher priority. Per package, per group or per pattern. Do not update - notice if they can be resolved. For handling manually. Maybe just rebuilt slackpkg to modularize so everyone would add its own module. Share with others - test and etc. Kind of /etc/rc.d/rc.local. And prioritize modules.

This already exists, as I reminded you in post #2, so no change is needed in slackpkg. Rather, you need to carefully read the man pages:
man slackpkg
man slackpkg.conf
and the file /etc/slackpg/slackpkg.conf that includes enlightening comments.