'shntool' package unavailable

Support
1

Hi centos => AlmaLinux group,

Can I ask a question which is not really enterprise related?
Sometime I struggle with packages in different distributions of linux.
During these times, I am lost, I keep searching , and I am not finding the answer.

Can I show it to you with this example, which is in fact more a desktop kind of functionality.

I tried to extract a cue and flac music files to individual files.
The packages needed for this function are generally in most distributions:

cuetools shntool flac

So, I tried sudo dnf install cuetools shntool flac

But if fails on the package ‘shntools’ since it doesn’t seem to be available for
red hat / centos / almalinux. Even if I installed the known EPEL repository.
Ok. So I tried to search the net for other possible repo’s that could hold this package in centos ,but no results at all.
In then end I used a debian system to install all 3 packages and I reach my goal.

My question:
In examples like this, what is the way to find unsupported packages like for centos / almalinux?

Sorry, if anyone is annoyed by the term ‘centos’, but I just came over form centos8, and i need some time to get used to alma thinking…

Thanks in advance for any help.
Dirk.

2

That is a good question. By nature, EL (Enterprise Linux; RHEL, CentOS, Alma, Rocky, Oracle, etc) has more “focused” subset of applications.

Websearch shows that a third-party repo did provide shntools for old EL versions, but that repo is long gone. Same search shows that recent Fedora have the package.

One approach is to take source package from Fedora and rebuild for EL. That can become a rabbit hole.

Another is to send a request to EPEL. They might be willing to build it for EL.

There are now flatpacks, snaps, containers or something that might facilitate “foreign content”. Just don’t put unpackged files among managed files in system directories.

1 Like
3

I use pkgs.org to search for packages that are not in the default repositories. shntool is not listed for RHEL/Alma/Centos/Rocky. It is listed for Fedora 35. I was able to take the source rpm listed for Fedora 35 and compile it for Almalinux 8.

Sounds like a project for the holiday.

4

Not really, I also rebuilt shntool-3.0.10-25 from FC34 src.rpm for Alma. It works very well and it’s not a difficult rebuild (just rpmbuild -ba shntool.spec ). Of course, you need to satisfy the -devel dependencies (I dont’ remember if it asks for any…), but what I wish to say is that you don’t need to modify the source code to obtain a working rpm build.

5

This is one of the problems that stops Linux really taking off and obliterating Windows. It’s a mess. It could be fixed, but that would require the different distro managers to do a bit of give and take.

Using things like containers is not a good solution, when you end up installing the equivalent of 2/3 of a (slightly) different OS just to be able to run a tiny binary. The better answer is for developers to wean themselves off shared libraries and move (back) to static linking - and before there are complaints about how big that would make the binaries – how big is the same app wrapped in a container? and how much does it complicate the networking on the destination machine simply to run it?

6

The containers got hugely popular because application developers see no need to support anything other than container version. That is significant cost reduction for the developers, but as you said has a cost for user.

I do prefer the ./configure && make to get “native” app. Alas, there are N+1 conventions and source builds are not as manageable as packages.

7

@Philip - I agree about static linking. with modern systems running to many GiB of real memory and TiB of storage, do we really still need to employ the tricks of a 1980s machine with 100 MiB of disk and a few MiB of memory?

8

Does static linking have some limits?

Say, a 32-bit program uses X11, Qt, and old versions of OpenGL and CUDA. Could it have been linked statically and how long will it remain “compatible”?

9

That of course depends upon two things: (1) how much you link in (for instance is QT linked?) and (2) how well written and maintained the interfaces are. I’ll be honest here, I did most of my programming under VMS and there were very strict interface rules between user code and Run-Time Libraries (RTLs). Most user level code could be run over major version changes, it just wouldn’t utilise the newer features. Yes obviously there are limits, but are they being compounded?

10

Thanks to you all for your help. Very interesting. Sometimes for a beginner it could be helpful to have not to many options and follow some direct instructions.

Joebeasley,

Thanks you for this practical answer, I see now I can use pkgs.org, to eliminate the question, does a certain package “X” exist for Almalinux. After I find the listing to be empty for a package, I can choose to install it from sources or choose another Linux distro for my humble needs.

Next question:

when I build a package from source, some sources on the net inform that it is needed to rebuild again when security updates packages come. If so, I need to remember that, which practically not happen. Is this correct?

If I choose to compile from source, what is the best manual to follow for almalinux? I did some compiling on a ubuntu system, but it seems the
“./configure && make” [jlehtone] procedure is somewhat different for centos / almalinux.

What remained a question for me in other rebuilding attempts, if you want to remove a rebuilded package, how to get rid of it again, in a clean way, without damaging the system?

11

How to build from source does depend on source.
I’ve seen sources that have just instruction to compile; have plain Makefile; have GNU Build Tools, i.e. the configure script; have config for cmake; tell to run pip install; etc. A nicer example: “SLURM”. Its sources are a tarball, but it contains spec-file so one can create RPM-files with rpmbuild.

How to convert sources into executable (be it binary or script) is one step.

The other step is the “install”. If there are executables, libraries, config, and data files … how to make them accessible.

I bet that neither Ubuntu nor EL likes if you drop file in /usr/bin/. Neither package manager knows that the file is there. One day you might install package that provides file with same name and silently overwrites your “from sources” file.

The usual directory prefix for make installrules is /usr/local. There are probably less content from packages, but you can still overwrite by accident, when you install more from other sources. Furthermore, regular user can’t write to /usr/local?

What I do is I’ve set up directory that does not collide with anything and where I can write as regular user. Each “from sources” is installed into unique directory under it. (Similar to “Program Files” in Windows.) No overwrites and several versions of same program can stay installed.

The problem is that you want executables on PATH, libraries so that dynamic linker finds them, etc, and you want to find via PATH the version that you want to run. For that I have installed package environment-modules and do create a “module-file” for each from sources program. The file defines changes to shell environment, e.g. PATH, etc.

When I want to use a program, I can with module load update current shell’s environment to make that program (version) findable and usable.

This approach is not specific to EL distros.

1 Like
12

Yes, you will have to recompile if a security update is released.

If you are talking about compiling from source (not source rpm), the source usually comes with an INSTALL/README file giving instructions on how to compile.

13

Hi @leeuw,

Good suggestion; here we go:
  1. set up a rpm build enviroment (info source: HowTos/SetupRpmBuildEnvironment )

1.1) open a command line terminal and switch to root (notice the # sign of the prompter: # for root, $ for a regular user)

su

enter your root password here, as root, enable the powertools repository:

yum install dnf-plugins-core
yum config-manager --set-enabled powertools

1.2) now proceed to set the build environment:

yum install rpm-build
yum install redhat-rpm-config

and finally exit the root account and get back to your regular user

exit

as regular user:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

now get back to root and install the compile tools:

su

enter again your root password, then:

yum install make
yum install gcc gcc-c++

1.3) as root we also need to install wget:

yum install wget

exit from root back to your regular user account:

exit
  1. search for the package we wish to install, as @joebeasley suggested:

2.1) open a browser, go to https://pkgs.org/ and search for “shntool”. Open “Fedora 34” tab and click on the “shntool-3.0.10-27.fc34.x86_64.rpm” link. Scroll down to “Download” section and copy the link for the source (code) of the rpm package. We will use this link to download the src.rpm package.

  1. As regular user (not root !), download the src.rpm file; type in the command line terminal:
cd /tmp
wget https://download-ib01.fedoraproject.org/pub/fedora/linux/updates/34/Everything/SRPMS/Packages/s/shntool-3.0.10-27.fc34.src.rpm
  1. install the source in the rpm build environment we just created before (as regular user, definitely NOT as root !)
rpm -ivh shntool-3.0.10-27.fc34.src.rpm
  1. proceed to the compilation (aka rpm building from source)
cd ~/rpmbuild/SPECS

where you find the “specifications” file for the rpm we wish to build ( shntool.spec ) and launch the compilation:

rpmbuild -ba shntool.spec

Oops, it complains about the lack of “autoconf” and “automake”… No problem, let’s install them

  1. Install the required dependencies (as root), then switch back to a regular user:
su
yum install autoconf automake
exit
  1. After installing the required dependencies, let’s’ try once again the compilation (as a regular user: NEVER build rpms as root !!!)
rpmbuild -ba shntool.spec

This step should end up without errors;

  1. the rpm package we built is located in:
cd ~/rpmbuild/RPMS/x86_64
ls -l

8.1) we can safely remove the “debug” packages:

rm *debug*
  1. and finally install our rpm (as root)
su
yum install ./shntool-3.0.10-25.el8.x86_64.rpm
exit
  1. after exiting root, enjoy shntool compiled by yourself
shntool -v

Regards,
Bogdan

Later edit:
If you wish to remove shntool you installed, just run (as root)

yum remove shntool

The procedure is very clean as long as you deal with rpms and not with “make install” or “make uninstall” tricks (these last two are not really recommended unless you know very well what you are doing).

1 Like
14

bogdan_ro,

Thank you! That is one really monkey proof manual you have written there!
Also It think it will motivate others to leave the sinking centos8 ship and choose for Almalinux instead. In my case, it gives confidence to know there is a good willing community behind almalinux, and if I need support even for silly non-enterprise related, offtrack user questions, there is someone helping out.
Also all others here, thanks for all insights.