LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-12-2019, 05:21 AM   #1
sairum
LQ Newbie
 
Registered: Sep 2004
Location: Portugal
Distribution: Slackware
Posts: 24

Rep: Reputation: 14
How to maintain a sane slackware64-current with Eric Hameleers multilib and ktown?


After more than two years happily living with slackware64-14.2 with no major problems I've recently jumped into Slackware64-current. The need of recent compilers to cope with some bioinformatics software, and the willingness to try a modern KDE (Eric's ktown for 14.2 is not being updated anymore) convinced me to take the leap.

Obviously, I've been a victim of yesterday's mesa/multilib problem... It took me a while to figure out why I've lost my X (XFCE didn't work either) and I had to do a lot of research with text based browser 'links' before I realize what an explosive mix is the automatic upgrade of Slackware-current together with Eric's multilib and ktown (plus Ponce's slackbuilds for current)!

So I wonder how other fellow Slackware users do when they have a similar configuration (Slackware64-current, multilib, ktown). My setup is as follows:
  1. Script that rsyncs Slackware64-current weekly

    This rsync excludes kde/ and kdei/ as they are not needed anymore if you install Eric's ktown. Hooray! Thank you Eric and happy birthday.

  2. Script that rsyncs multilib and ktown weekly

  3. Script that moves whatever is in Slackware64-current that conflicts with multilib and ktown. So far, the script does the following

    1. Moving glibc* and gcc* from a/ l/ d/ folders to a backup folder so that they don't overwrite multilib when I do an 'upgradepkg slackware64/*/*.txz'

    2. I've identified the following packages that should also be excluded from Slackware64-current

      • n/gpgme
      • l/PyQt
      • l/QScintilla
      • l/grantlee
      • l/phonon
      • l/qt-gstreamer
      • l/sip
      • l/akonadi
      • l/poppler-[0-9] # There is a poppler-data that is not in Eric's ktown which I keep installed

  4. upgradepkg slackware64/*/*.txz

  5. upgradepkg multilib/*.txz and multilib/slackware64-compat32/*/*.txz

  6. upgradepkg ktwon/x86_64/deps/*.txz and ktwon/x86_64/kde/*/*.txz

What are your thoughts?
 
Old 05-12-2019, 05:30 AM   #2
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,499

Rep: Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827
You could have a look at slackpkg+ which is a community extension to add support for 3rd party repositories to Slackware's slackpkg tool. I wrote an article about how I use it: https://alien.slackbook.org/blog/int...-repositories/
 
4 members found this post helpful.
Old 05-12-2019, 05:52 AM   #3
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 970

Rep: Reputation: 538Reputation: 538Reputation: 538Reputation: 538Reputation: 538Reputation: 538
there's also slapt-get and the gslapt gui:
https://software.jaos.org/

Quote:
some bioinformatics software
just out of curiosity, what are you using?
 
Old 05-12-2019, 08:32 AM   #4
sairum
LQ Newbie
 
Registered: Sep 2004
Location: Portugal
Distribution: Slackware
Posts: 24

Original Poster
Rep: Reputation: 14
As AlienBob suggests, slackpkg+ is always an option. Unfortunately, I had a really bad experience with it a couple of years ago or so, so I switched to a more controlled (in the sense of less automated) environment, totally based on tailor-made shell scripts. It served me very well until I switched to current. Maybe it's time to try it again. I've never tried slapt-get...

I would ditch 'multilib' if I could, but it's required by Cisco's Checkpoint VPN, which only provides a 32bit linux client and it's mandatory to connect to my University Network. This would simplify a little the maintenance of Slackware-current as I would have only to take care of new KDE stuff...
 
Old 05-12-2019, 09:21 PM   #5
akimmet
Member
 
Registered: Jul 2018
Location: NW Ohio, USA
Distribution: Slackware64 -current
Posts: 35

Rep: Reputation: Disabled
I also recommend using slackpkg+.

Once I have gotten it properly configured, it hasn't failed me yet.

The only issues I have ever had were ones that have occurred from updating without checking the changelogs and the forum here first.

Here is my routine for updating -current with slackpkg+:

1. Read http://www.slackware.com/changelog/c...php?cpu=x86_64

2. Check https://alien.slackbook.org/blog/

3. Check this forum. I have saved myself countless times just by checking here before updating.

4. Then I run: slackpkg update && slackpkg install-new && slackpkg install ktown multilib && slackpkg upgrade-all
NOTE: "slackpkg install ktown multilib" is very important! "slackpkg install-new" won't automatically install new packages in 3rd party repositories.

5. Review any new config files. I usually overwrite the .new files over any old config file I know I haven't modified.

6. Update the boot loader. I use elilo, so I just copy the latest kernel to my EFI partition.

7. Occasionally I'll remove any stale packages that have been removed or superseded: slackpkg clean-system
WARNING: This will list any package that you have installed and isn't in a repository checked by your slackpkg+ config! It may be a good idea to blacklist any important package not in a repository to prevent mistakes.
 
Old 05-12-2019, 10:30 PM   #6
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 127

Rep: Reputation: Disabled
@akimmet's workflow is a good one, but I suggest some improvements:

- Avoid upgrading kernel with slackpkg+. Uncomment the proper entries in /etc/slackpkg/blacklist.

- Keep at least one previous version of a kernel you know it's booting fine. You might need it to recover from the unexpected. Boot loaders could handle that just fine.

- Keep copies of old glibc-solibs, icu4c and boost before updating your local mirrors. These are the packages who gave me headaches while upgrading in the last years.

Bellow is the command I use to preserve the packages before I update the mirrors:

Code:
# Clean up and preserve sensitive packages
echo "[BEGIN] Cleaning up and preserving sensitive packages (glibc-solibs, icu4c, boost, kernel)..."
find /volume1/mirrors/slackware64-preserve/ -type f -mtime +180 -delete
cp -af \
  /volume1/mirrors/slackware64-current/slackware64/a/glibc-solibs* \
  /volume1/mirrors/slackware64-current/slackware64/l/icu4c* \
  /volume1/mirrors/slackware64-current/slackware64/l/boost* \
  /volume1/mirrors/slackware64-current/slackware64/a/kernel-firmware* \
  /volume1/mirrors/slackware64-current/slackware64/a/kernel-generic* \
  /volume1/mirrors/slackware64-current/slackware64/d/kernel-headers* \
  /volume1/mirrors/slackware64-current/slackware64/a/kernel-modules* \
  /volume1/mirrors/slackware64-current/slackware64/k/kernel-source* \
  /volume1/mirrors/slackware64-preserve/
ls -1 /volume1/mirrors/slackware64-preserve
echo "[FINISHED] Cleaning up and preserving sensitive packages."

Last edited by denydias; 05-12-2019 at 10:41 PM.
 
1 members found this post helpful.
Old 05-13-2019, 01:39 AM   #7
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,499

Rep: Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827
Fully agree to denydias' remarks wrt kernel upgrades. As for glibc-solibs I never had an issue with upgrading it, as long as the upgrade is part of upgrading all the glibc packages and as long as the glibc packages are upgraded before any other upgrades that were released by Pat in the same batch.
Boost and icu4c are always a pain in the *ss which is why I now have "boost-compat" and "icu4c-compat" packages in my own repository. These packages contain several older releases of the libraries for boost and icu4c, and by installing these two -compat packages you'll never be bitten by an upgrade in slackware-current.
 
2 members found this post helpful.
Old 05-13-2019, 02:32 AM   #8
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 127

Rep: Reputation: Disabled
Quote:
Originally Posted by Alien Bob View Post
As for glibc-solibs I never had an issue with upgrading it, as long as the upgrade is part of upgrading all the glibc packages and as long as the glibc packages are upgraded before any other upgrades that were released by Pat in the same batch.
It should not cause troubles indeed, unless one decides to follow Upgrading Slackware to a New Release recommendations (my case). It says:
Quote:
A new Slackware release usually has a newer version of the GNU C libraries. The new packages are compiled against that new glibc version. In order to prevent an upgrade failure, you need to upgrade the glibc-solibs package manually, immediately after upgrading slackpkg:
If this step fail for whatever reason, I see no harm on having a previous glibc-solibs around. Never happened though.
 
Old 05-13-2019, 09:32 AM   #9
akimmet
Member
 
Registered: Jul 2018
Location: NW Ohio, USA
Distribution: Slackware64 -current
Posts: 35

Rep: Reputation: Disabled
I do indeed have boost-compat and icu4c-compat already installed. I consider these both essential if one is using ktown and/or alienbob repositories.
Yes, it's true. I have been living dangerously with kernel updates. However, I have been using Slackware-Live to fix things in the rare event of a broken kernel.
 
Old 05-14-2019, 10:42 AM   #10
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 943

Rep: Reputation: 366Reputation: 366Reputation: 366Reputation: 366
This is what I do.

I mirror slackware64-current daily. Both multilib and ktown are mirrored manually using scripts that mirror the parts I want (source and packages for slackware64-current). I use the RSS feed for both multilib and ktown to monitor for updates.

I never upgrade the kernel. I keep two kernels, the new and the last installed. I do a removepkg oldest, installpkg new, which leaves a last working kernel. On boot I have two options Slackware64 and LastWorking. I don't install the huge kernel, it's permanently blacklisted. I use 'slackpkg download' to download kernel-generic, kernel-modules and kernel-source which requires I temporarily comment them out in the blacklist file. The kernel-firmware and kernel-headers are upgraded normally with slackpkg. I update the symlinks in boot for the working kernel, use mkinitrd to create a initrd.gz and initrd-working.gz (e.g. my last upgrde: 'mkinitrd -F -k 4.19.42", then 'mkinitrd -F -k 4.19.40 -s initrd-working-tree -o initrd-worknig.gz') then of course run lilo. I've consider writing a script to do everything.

I use slackpkg (w/slackpkg+) to manage multilib and ktown, plus a few alienbob packages and my own package repository called nonslack along with slackpkg+. While using slackpkg (w/slackpkg+) does work for ktown, occasionally something is missed and upgrading it per the README has always fixed it, so I have a script that upgrades ktown per the README. I do use slackpkg (w/slackpkg+) for small ktown updates as we recently had with 5_19.05.

Multilib is managed by slackpkg (w/slackpkg+).

In using slackpkg (w/slackpkg+) it is important to remember that 'install-new' only works for slackware64-current packages only. If I have new packages in multilib and nonslack (my repository) I would would issue the command as follows:

'slackpkg install multilib'
'slackpkg install nonslack'

Yes I could run that as 'slackpkg install multilib nonslack'

There was a recent Add. to ktown I refreshed my mirror then ran:

'slackpkg update'
'slackpkg install ktown'

This listed the new package and allow me to install it.

Having all third party installed packages in a repository is the easiest way to manage updates to slackware64-current with slackpkg (w/slackpkg+).

If everything is upgraded packages a simple slackpkg upgrade-all will handle everything. In my case the upgraded packages come from my local slackware64-current, multilib and ktown mirrors, my local nonslack repository. The alienbob and slackpkg+ packages are download from the respective repositories. At one time I had incorporated the alienbob packages I use in to my repository.

My local mirrors are all installed off /home/. Slackware is install at /home/Slackware64-current/, multilib at /home/non-slack/multilib/ and ktown at /home/non-slack/ktown/. My repository is installed at /home/non-slack/slackbuilds/. The attached screenshot shows the layout of my repository. I use Alien Bob's gen_repos_files.sh to create the repository to work with slackpkg (w/slackpkg+). The first expanded tree shows an Alien Bob package directory with two scripts. One uses lftp to mirror the build tree, the other uses wget to download the package (if I can't get it to build). There are no packages as I now just let slackpkg (w/slackpkg+) take care of those directly from Alien Bob's repository. The second expanded tree show an example of my build environment. The build, oldpkgs and tmp directories are excluded from the repository generation. Only the package is used, the rest of the package related files are created by gen_repos_files.sh. I did have to make a small modification to gen_repos_files.sh to get those directories and the files, directories below excluded from including in to the repository.

Since I use the NVIDIA blob for my graphics, I reinstall it after every kernel, mesa or xorg-server upgrades.

I find that most of my 'nonslack' packages don't need a lot of recompiling. I don't recompile everything after updates to slackware64-current. There are obvious cases such as when boost or icu4c are updated. I know pretty much what needs to be recompiled. A great tool for helping with figuring things out is sbbdep.

With the last gcc update or more accurately the first of the 9.1.0 updates I did have one issue. Since multilib is installed gcc was not upgraded by slackpkg (w/slackpkg+), but one package that was upgrade did cause a problem. My feedreader QuiteRSS would not start or rebuild. Since I know why I just waited for the multilib gcc packages to be released. I went a day without using my feedreader. No big deal. After the multilib upgrade, all was well.

Code:
d/libtool-2.4.6-x86_64-11.txz:  Rebuilt.
  Recompiled to update embedded GCC version number.
One note on ktown and multilib. One main reason I manually refresh these mirrors vice using a cron job. If they are automatically updated then when I issue a 'slackpkg update' (w/slackpkg+) those updated packages will be included when I issue a 'slackpkg upgrade-all'. I may not want to do that yet. This is especially important with ktown. The most common reason for delaying a ktown upgrade was boost and icu4c. Before Alien Bob created the boost-compat and icu4c-compat package it was virtually guaranteed to break ktown. Now it not an issue but still I don't want to be caught with an updated mirror when I do a 'slackpkg update' followed by a 'slackpkg upgrade-all' and see a ton of ktown packages show up. If there is a big ktown update available I make sure everything else is updated first. Then refresh the ktown mirror and then install ktown.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
upgrading slackware64 13.1 multilib to slackware64 -current multilib Cultist Slackware 4 03-12-2011 09:04 AM
Interview with Eric Hameleers: Why You Should Try Slackware Bruce Hill Slackware 33 06-12-2010 03:38 PM
An Interview with Eric Hameleers - You should try Slackware! cousinlucky General 2 09-03-2009 02:14 PM
Interview with Eric Hameleers tangle Slackware 1 09-03-2009 09:48 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:10 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration