I'm using LiveSlak(64) 1.1.5 -current. I plan to manually manage updates for
multilib, and chromium packages, while leaving ktown at 5_16.12 unless
AlienBob's RSS feeds indicate any security or stability issue needing
a fix. I decided not to upgrade to Plasma/KDE 5_17.01 after reading reports of vi,
dolphin issues and AlienBob mentions many new Plasma and KDE program changes I'm not
ready to tackle at this time. (I'm also experiencing a rsync issue but that's another thread.)

However, I'm thinking to keep -current up to date might be a larger undertaking than I'm
anticipating. So I'm seeking some expert advice. So all you experts out there please help.

1) IF a person wants to stay on LiveSlak 1.1.5 -current,
what is the best configuration for a blacklist so it doesn't damage the configuration I've mentioned above? My current slackpkg.conf
is the standard defaults provide in the LiveSlak ISO and my blacklist is following:

# NEVER upgrade kernel's on a working system.
kernel-firmware
kernel-generic
kernel-generic-smp
kernel-headers
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-source
[0-9]+_SBo #locally built Slackware packages
[0-9]+alien # don't break KTOWN packages
[0-9]+compat32 # don't break multilib packages

I believe, when running slackpkg updates, this will show me Pat's
updates to -current as long as they don't conflict with any fixes with AlienBob
tags (ie alien and compat32). Then I'll have to manually compare Pat's changelog and Eric's KTOWN/Multilib changelogs to see if there are security/fault updates of later version to manually apply, keep them from conflicting with multilib versions, then
download and apply using upgradepkg. (Usage of slackpkg+ is problematic and discribed on another thread.)

2) Is it any more complicated than that?

Oh.. I know this sounds like why don't I simply reload to 14.2 with slackpkg+ for alien/multilib/ktown/restricted and use Eric's KTOWN for 14.2 which won't see as much activity. However, -current is stable enough for my needs (only had issue with libinput/libwacom causing keyboard non-function) in six months of use. I'm liking SDDM, VLC and LibreOffice. I also have already compiled GNUCash/Claws-Mail/Brave/XnView/PaleMoon as local packages, which I believe would need to be recompiled since the gcc and glibc libraries would be incorrect and possibly incompatible. I'm also successfully running kernel 4.9.5 and I'm not sure 14.2 is supported on 4.9 kernel at this time?

Advice is appreciated. Cheers BrianA_MN

You may want to get his 1.1.6 version of his iso2usb.sh script, as it supports a -r option allowing you to refresh the stock packages without affecting user data.

http://bear.alienbase.nl/cgit/livesl...usb.sh?h=1.1.6

However, if you used his Plasma5 ISO to create your usb drive, this wouldn't work, since it would upgrade your ktown. But if used a regular Slackware ISO and added ktown and the other various packages after that, then this should work fine.

Overall, I believe if you just upgrade your packages, I think it just adds the packages to the thumbdrive without actually removing the original ones. Instead, I believe it just "overlays" the package over the new one, so you'd end up with double the space being used.

1 members found this post helpful.

Refreshing your liveslak installation with "iso2usb.sh -r" is an option you should consider indeed.

On top of that, you might want to consider creating squashfs modules out of the packages you compile instead of installing them into liveslak. While the latter just works as bassmadrigal states you get an evergrowing "persistence" overlay consisting of the files you installed. The liveslak will not get smaller (files that are "overwritten" by upgradepkg are simply masked out, so eventually your USB drive may fill up. If you use the "makemod" script to make a squashfs module and copy that into the "liveslak/addons" subdirectory on the USB drive then management will become a lot easier as liveslak will load the addons transparently into the Live filesystem and will keep doing so even if you refresh the Live OS with "iso2usb.sh -r".


Mind you that the writable persistence overlay sometimes may become corrupted or prevents the Live OS from booting, in such cases it may become necessary to wipe all alterations from the USB drive and start "fresh" again, but with a preserved /home if you opted for an encrypted /home container. The boot command parameter to wipe the overlay and start with a fresh unaltered Live OS is "nop=wipe"

But if you do not care about all of that, that's just fine too. Use slackpkg/slackpkg+ to keep your packages up to date. That will work just as well as in a real Slackware installation.

2 members found this post helpful.

Thank you for the responses. The answers as regards to using a USB stick I'm sure will be valuable to others.
I'm still interested in answers to my two questions, which relate to my installation on my hard drive. Setup2hd, was used to install the packages on the LiveSlak Plasma5 DVD to my hard drive. I understand that either slackpkg or slackpkg+ can be used for updates. My questions are related to only using slackpkg not slackpkg+.
LiveSlak is a "snapshot" of -current as of 12-10-16, plus Plasma5, KDE 5_16.12, multilib, SDDM, Lumina and LXQT. So I'm asking is the blacklist proper and is my logic for how to manually update multilib, ktown correct or are there other issues to consider? Cheers BrianA_MN

I didn't know you installed it to your harddrive. I glanced back through your post and still don't see it mentioned... not sure if I'm just missing it or it wasn't actually included. That changes things drastically. Also, just for some clarification (since Eric clarified it for me earlier), liveslak is the collection of scripts. Slackware Live is the resulting iso that can be dd'd to a usb drive/dvd, or be used with iso2usb.sh to create a Slackware Live install that has persistence. Once you used setup2hd, then I believe there is no need to use any of the liveslak scripts.

When it's installed on the harddrive using setup2hd, I don't believe there is anything that is different from doing a normal install. It wouldn't be considered "liveslak" as that isn't any kind of distro, it's just a collection of scripts. You're running Slackware-current with plasma5 and multilib. Since you used the Plasma5 disc, it will be slightly different from a normal Slackware-current install since it replaced several stock packages (which you are already aware of).

Based on that, yes, it seems all you need to do to ensure the non-stock packages (ktown, multilib, etc) aren't updated would be to have them listed in the blacklist like you have. That will prevent any of those from being updated.

However, be warned, since -current is a moving target, many libraries over time will be upgraded, many of them will be incompatible with the older versions. If ktown is compiled against the older versions, once you install the newer ones, your ktown will likely break. The same goes for multilib. If you try and upgrade -current, but keep ktown at its current version, you will likely run into a break at some point, and the only fix would be to upgrade ktown to a version that is compiled against the newer library in -current. You will likely run into those same issues with your SBo packages, however, those should be relatively easy to recompile against the newer libraries.

But, where the Flash copied to the hard drive and remained packed in the live form...

on my (ever growing) TODO list

Bassmadrigal is 100% spot-on.
If you install a Slackware Live OS to your harddisk, it will effectively become a real Slackware installation. The 'setup2hd' script will not install any of the modifcations that are needed to make a Live OS. Consider the 'setup2hd' of Slackware Live an alternative to the 'setup' script of a genuine Slackware installation medium. The process is a bit different, the end result is exactly the same if you were running the SLACKWARE Live ISO.
Of course, when you boot a PLASMA5 Live ISO and use 'setup2hd' you will get much more than just Slackware - you'll get Plasma 5, lots of my own packages (VLC, LibreOffice, Chromium, etc) and multilib, all at once, so you do not have to go through the manual upgrades/additions yourself.
Plus, installing from the Live OS to your harddisk has the advantage that the installation will happen in a X terminal. It leaves you to use your computer as you like: surfing the web, playing videos, listening to music, reading emails, writing documents etc.

What would be the rationale for that? It will only limit you.

bassmadrigal and AlienBob thanks for the response of the accuracy of my blacklist and other things I need to be aware of. I had not considered -current causing KTOWN/MULTILIB breakage. However, I believe most of that is going to libraries that are replaced and need symlinks or have some reference removed, like aaa_elflibs dropping and adding references to files. I'll have to carefully consider that point.

AlienBob on the other side, dependencies for KTOWN usually are included in the changelog notice or the individual packages, yes or no?
Or is it "assumed" that -current is always up to date so newer KTOWN will have the necessary base versions files or new files necessary to run?
I understand KTOWN may also replace a -current file (will have an alien tag) in order to support a KTOWN function and then -current's update won't be effective since the blacklist will block the update.

Multilib version issues should be overcome with recompiles using compat32pkg. Alternatively a full refresh could be done, just like the manual install process in AlienBob's Multilib Slackdocs page instructions.

In fact this past Sunday I did a slackpkg update for -current. Noted that some current updates weren't applied because of "alien" tags. Then on Monday I followed the multilib manual install process to refresh multilib on AlienBob's notice of refreshed packages for current. When I went to refresh KTOWN is when I noticed that there may be reasons to wait for some stability concerns. Thursday I plan to update LIBREOFFICE, WINE, OpenJDK, and CHROMIUM. Thus far everything critical is running without issues. The only thing I've noticed is that LXQT and KDE aren't starting which I believe is because I'm running libinput 1.6.0 and the KTOWN of 5_16.12 was probably compiled with libinput 1.3.3? In the meantime I'm running WindowMaker or (FVWM/XFCE) for WM/DE and LibreOffice suite and removed Calligra totally. My KDE interests are more tools and games. I don't use Adobe/Oracle products and try to avoid proprietary blobs if possible (ex. nouveau rather than NVIDIA for my NVIDIA card). But I'm not getting any programs crashing due to my process. Thanks again to all the expert advice.
Cheers BrianA_MN

My rationale:
1. being layered means all changes are contained - so can't damage any part of the OS (in everyday operation)
2. the OS, being RO, saves access times considerably, loading of the OS is lighting fast
3. Per session, the changes can be saved or discarded.
4. Data separation is complete: OS is untouchable, user data is 100% separate, entropy is 100% contained and manageable.

This, in my head, sound like the ultimate sever platform?

#1 and #4 can be accomplished using overlayfs and some minor tweaking of the startup scripts (to start the chroot), which has been a part of the kernel since 3.18. #3 is capable of doing that with overlayfs with a bit of modification of the system to allow session resuming or discarding on startup. With #2, I don't know why having something as RO would increase the speed. If you don't want access times updated, there are simple mount flags to adjust that.

Sorry this is not the right place for asking this. But there is any thread only about liveslack?
It would be nice to get that on sticky.
Or maybe a subforum.

I'm using liveslack on USB Pen Drive. To keep up with current and test things.
It's amazing!

Thanks all you guys that are making this possible.

Eric prefers to keep discussion about his projects on his blog. That's where he'll announce updates as well (he just posted one on 16 FEB).

http://alien.slackbook.org/blog/tag/liveslak/

1 members found this post helpful.

Just to mark as solved and also to state that I'm not having any issues with the process I proposed in post 1. Cheers, BrianA_MN

I'm guessing he will put the OS on an SSD and the changes overlay on an HD.
That would indeed speed things up and, since the OS is read-only, it would extend the life of the SSD.