Slackware-current 64 bit, pure-alsa, how to manage updates for pure-alsa-system?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
So that it becomes:
PRIORITY=( patches extra %PKGMAIN pasture testing )
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.
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 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.
Agreed. I'm no longer using the pure-alsa-system. I've moved that unit to OpenBSD 6.4.
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.
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?
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.
Quote:
Originally Posted by hitest
Agreed. I'm no longer using the pure-alsa-system. I've moved that unit to OpenBSD 6.4.
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.
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.
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?
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.
Probably one of possible solution is to add priorities to slackpkg.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
