[SOLVED] A quick question about updating Ruby...

Hiya gang,

Can it be done if I use the source code from here, for instance? https://slackware.nl/slackware/slack...source/d/ruby/

Or is the system always going to be looking for the stock ruby 3.0.3 that came with 15.0?

Just curious, as I've been a player on Gemstone since the *very* early AOhHell days. I can now build something I can use to play the game without having to get even slower (satellite is severely bad for this game and pretty much all these type games, unfortunately) using a javascript website thing, and can build something called 'lich'.

To use the very latest 'lich', I need ruby 3.2 or later, so I was just hoping and wondering about my questions above. Thanks.

The best way to get an upgrade is to download the contents of /slackware/slackware-current/source/d/ruby/ from your local mirror. I have just tried http://slackware.uk/slackware/slackw...source/d/ruby/. Run the slackbuild as root. Then upgradepkg /tmp/ruby-3.3.0-x86_64-1.txz. This will build ruby against your slackware install. The pre-built one will not work because it is linked against updated libraries that you don't have. Enjoy.

Kind regards

Dunc.

Great! Thank you!

I'd like to add this. The ruby.SlackBuild in 15.0 and in -current are the same. I do this sort of thing all the time. I also tested this in my 15.0 VM, it worked, fair quite compile time to. There are three packages in slackware64-15.0 that after compiling and installing the new ruby (if you use them) that will need to be rebuilt: epic5, marisa and subversion. Basically just run the SlackBuild in each of those programs "source" directories.

When you rebuild ruby, I would at least give the new package a tag, at the bottom of the SlackBuild find "$BUILD" change it to:

${BUILD}tag

Rename "tag" with what you want. I use "cgs" for my packages. You could for example use "ftio", the resulting package named "ruby-3.3.0-x86_64-1ftio.txz".
Edit: An easier way to set the tag. Every Slackware SlackBuild has a this at the top:

BUILD=${BUILD:-1}

Add the tag after the build number:

BUILD=${BUILD:-1ftio}

You could also pass the 1cgs through the BUILD variable:

BUILD=1ftio ./rust.SlackBuild

If you have already created the new package, you can simply rename it.

I would do the same for the the packages to rebuild if you rebuild them.

Why to tell them about from "stock" Slackware packages and make them easier to blacklist in you are using slackpkg.

[0-9]ftio

in /etc/slackpkg/blacklist

Do you use slackpkg with the slackpkg+ plugin?

chrisretusn is so right. I have fallen into that trap more than once. Upgradepke is brilliantly stupid. If the numbers are different on the same name it updates. Once you know this reverting packages becomes easier. So changing the name with the build tag protects it from routine updates.
Thanks for the tip.

Dunc.

Thanks Dunc. That is not why I recommended adding a tag. Upgradpkg will upgrade what you tell it to unless the packages are identical.

If both "ruby-3.0.6-x86_64-1_slack15.0.txz" and "ruby-3.3.0-x86_64-1ftio.txz" available in the current directory:

1. ruby-3.3.0-x86_64-1ftio.txz is installed, 'upgradepkg ruby-3.3.0-x86_64-1ftio.txz' will not upgrade, it's already installed.
2.ruby-3.0.6-x86_64-1_slack15.0.txz installed, 'upgradepkg ruby-3.3.0-x86_64-1ftio.txz' Will upgrade ruby-3.0.6-x86_64-1_slack15.0.txz to ruby-3.3.0-x86_64-1ftio.txz.
3. ruby-3.3.0-x86_64-1ftio.txz is installed, 'upgradepkg ruby-3.0.6-x86_64-1_slack15.0.txz' will upgrade ruby-3.3.0-x86_64-1ftio.txz to ruby-3.0.6-x86_64-1_slack15.0.txz.

The the tag makes the packages different.

The very fact of creating a package for a newer version of ruby means this package is now a non-slack or third party package.

If using slackpkg without the slackpkg+ plugin, slackpkg 'upgrade-all' as well as 'slackpkg upgrade ruby' will upgrade the package to the "stock" slackware64-current package. slackpkg does not care about tags, it only cares about was is "stock" and what is "not stock". The only way to keep the new ruby-3.3.0-x86_64-1ftio.txz from being upgraded is to blacklist it, by package name, base name "ruby" or blacklist by the tag; e.g., "[0-9]ftio" which is useful if you have multiple packages with the ftio tag.

Now if you are using slackpkg with the slackpkg+ plugin. From this point on when I refer to slackpkg, I am referring to slackpkg with the slackpkg+ plugin installed. There are ways to handle these packages. One is to create a personal repository. This will require using a script to create the needed metadata files for slackpkg to use and a gpg-key for this repository. Useful if there are lot of third party packages. Another method is to put packages in a local directory. With this method no metadata files are needed. I to use both methods. I will describe the local directory method.

For this example I will use what I use the directory I use "/home/non-slack/justpkgs". Change to desired location. I will use the above ruby-3.3.0-x86_64-1ftio.txz for the package. "/home/non-slack/justpkgs/ruby-3.3.0-x86_64-1ftio.txz"

I then add this to /etc/slackpkg/slackpkgplus.conf (I added two commented out situational examples):

PKGS_PRIORITY=( justpkgs:ruby )  # Just one package.
#PKGS_PRIORITY=( justpkgs:.*ftio )  # Just packages with this tag.
#PKGS_PRIORITY=( justpkgs:.* )  # All packages in justpkgs..
MIRRORPLUS['justpkgs']=dir://home/non-slack/justpkgs/

That is all you need. The first tells slackpkg to use the ruby package in justpkgs, defined in MIRRORPLUS to upgrade the slackware64-15.0 package of the same name.

This is my slackpkgplus.conf (PKGS_PRIORITY, REPOPLUS and MIRRORPLUS) section (includes my reminder comments and comments "##" for this post):

# Set PKGS_PRIORITY to give priority order for single packages present in
#  multiple repositories or to allow repositories to override official
#  Slackware packages. Without this variable you cannot override official
#  Slackware packages. This only applies to 'slackpkg upgrade-all'
# NOTE if justpkgs is used, specify the package or if all packages
#  use ( justpkg:.* )
PKGS_PRIORITY+=( nonslack:ffmpeg-compat32 nonslack:mozilla-firefox )  ## This is my repository. only these two packages override slackware64. I could have use "nonslack" as there is nothing else named the same as slackware64.
PKGS_PRIORITY+=( multilib:aaa_glibc-solibs multilib:gcc multilib:glibc ) ## Same applies to multilib. I could have just used "multilib', I prefer it this way. 
PKGS_PRIORITY+=( restricted:ffmpeg )  $ This override slackware64.

# REPOPLUS is to specify the search order in the thrid party repositories
#  ('slackpkg upgrade-all'). REPOPLUS is filled (unsorted) from the keys of
#  MIRRORPLUS so it is possible to use only PKGS_PRIORITY and MIRRORPLUS.
REPOPLUS+=( nonslack )  # My local repository.
REPOPLUS+=( justpkgs )  # No metadata.
REPOPLUS+=( multilib )  # Using local mirror.
REPOPLUS+=( restricted )  # Using local mirror of only packages I use
REPOPLUS+=( alienbob )  # Using local mirror of only packages I use.

# These are associative arrays, order assigned does not mean order out. In
#  summary order here means nothing. The 'keys' of these arrays are used to
#  initially fill REPOPLUS. Order is set by order assigned with REPOPLUS.
# NOTE run 'slackpkg update gpg' with changes here.
# NOTE if you remove any big repositiries below, probably should
#  wipeout /var/lib/slackpkg and rebuild.
MIRRORPLUS['alienbob']=file://home/non-slack/alienbob/
MIRRORPLUS['justpkgs']=dir://home/non-slack/justpkgs/
MIRRORPLUS['multilib']=file://home/non-slack/multilib/current/
MIRRORPLUS['nonslack']=file://home/non-slack/slackbuilds/
MIRRORPLUS['restricted']=file://home/non-slack/alienbob_restricted/

As you can see above I like to put each repository on separate lines in the PKGS_PRIORITY and REPOPLUS section. Easier to what I have set and makes room for comments. the "+=" in the key. The adds to the variable instead of replacing it.

It is also worth mentioning that it is often better to leave the system Ruby intact. You can cause issues on your system by modifying the system ruby. Plus, Slackware is tested with the ruby version provided by Patrick.

What I typically do is install "RVM". https://rvm.io/

Then you can more easily install the ruby version expected by your application, game, utility. You can run it as a normal user. It is not recommended to install rvm and ruby into /root.