I was watching this very interesting video from Distrotube tonight which teaches newer uses how to install third party packages. They run through the configure/make/makeinstall method, the sbopkg method and finally sbotools. It occurred to me that different Slackware users must install third party packages in a variety of different ways and I'm curious to know who chooses what and what can be learned from these different methods.

I personally like to use a manual approach, but nevertheless one which isn't as involved as the first one in the video. I don't use configure/make/make install but I'm starting to think I should on occasion. I personally use the instructions on the SBo site though I've never followed step 4 since the script is already executable.

If there are quite a few dependencies I will hop on over to sbopkg but I will still go through SBo and input the dependencies in manually, even if there are ten or more. This way I feel I have a little more control. sbotools just feels 'too automated' for me, and I like reading about which dependencies I'm queuing up.

I'm fascinated by the old school configure/make/makeinstall method. To sketch it out, in the video the sequence for Leafpad was:

Now this was interesting, they changed to root using su rather than su - and I always use su -

copy slack-desc content

Now, this is all very well for packages with no dependencies, but I imagine doing so for a package with depends would be slightly more involved.

So what method[s] do you generally use, and for what reasons?

not really, because you are just running a slackbuild for each package.


Unless you create a script that will install all of the dependencies in the order needed to be installed, then the main package source then run it. which now that I wrote this, sounds interesting to try myself, having all placed into one slackpkg to be installed.

A slackbuild script is nothing more than having it using the old school. (configure) , make, make install,then copies it into a tarball that is specif for Slack so it can keep track of what is installed on the system.

if you use just (configure), make, make install, and do a clean system, whatever you installed like that the system does not know about and (should) still be there when it has complete cleaning the system down to the original install.

2 members found this post helpful.

This is what I find interesting, and it's my own failing, to an extent: I've never really looked at a Slackbuild script in detail. Of course, I suspected after watching the video that that's what it was doing. My method of manual SBo installs has caused the odd problem since I change to root before starting the whole process rather than just before the build. I've learned of late that that's not the ideal way to do things [my /home/lysander/Downloads folder had a load of things owned by root which shouldn't have been].

which is an easy fix. the way I do it is when I am not using sbotools, download the stuff i need, then put the tar into the dir where the slackbuild is, then
which I am sure some will argue should not be done that way.
so just download place tar in slackbuild folder
su - changes your user environment to roots.


you should open a few slackbiilds and read through them, even place echos in it to echo the vars to see what that is doing and such harmless things to figure them out.

chown to fix the files in your dir

If it's part of slackbuilds.org, I'll use slackrepo to build it.

If there's no slackbuild for the item, I'll try to use src2pkg to make one for me.

1 members found this post helpful.

I generally use SlackBuilds.org and build the packages the old-fashioned way, one at a time, via the command line, because I'm comfortable with it. ( You kids and your newfangled toys!)

I can't remember the last time I wanted to install a package that wasn't available through SlackBuilds.

When I started with Slackware, there was no SlackBuilds.org. I learned a lot more about dependency resolution than I ever wanted to know, but it was a valuable experience.

2 members found this post helpful.

I used to use SlackBuilds.org and do it manually.

Then I thought I'd write a script to do the (handful of) steps for me.

Then I decided to try and add rudimentary dependency handling to my script via parsing the $package.info file...

It's now more obvious to me how programs slowly add more and more features/bloat... :-)


Anyway, it works for me, and is much simpler than sbotools, et al.

https://github.com/Loomx/Git/blob/ma...cripts/sbotool

My first port of call is sbopkg.

Reasons:

1. Laziness (the slack is strong)
2. Ease of updates
3. It works very well
4. Builds can be queued

If the software isn't available on SBo, then the answer is: It depends.

If it's a single script or binary file, I'll just download or compile it and put it under /usr/local/bin without packaging it.

With VirtualBox, I use their binary installer to put it under /opt. Same goes for LibreOffice.

That covers most things for me.

1 members found this post helpful.

Not sure why you call those steps "old school", they are just the normal ones, and the package/application upstream documentation together with the configure (./configure --help can also be useful) script code are the ones you need to study for identifying dependencies. If you focus and specialize on some services, you might find yourself looking for some particular optimizations for the packages/applications you use for those services, ones that are maybe not enabled during the "stock" distribution package compilation. You can now either modify the existing build script provided by Patrick (in the source tree) or alternatively an existing SlackBuild and add your desired options, or go 100% the manual/normal way, by going through the steps you presented in your OP.
Following the instructions for creating a package under Slackware is recommended, although sometimes tricky, might need to prepare the compiled binaries&libs before actually packaging them -> you might get some clues by peeking into some SlackBuild scripts.

Back in the day when I had no 24/7 access to the Internet and learned BSD/Linux on my own, literally discovering it mainly with man & --help, I used to keep the whole compilation working directory - sources+compiled binaries, for which I usually also kept a strict path naming rule, e.g. /kit/app-name-vers-x-x-x/ , archived and used the "make install" and "make uninstall" targets for manual upgrades. I'm also using the (default) /usr/local/ prefix folder for my own compilations, just got used with it, it seems.
I'm still doing this now for smaller applications (mainly security/networking/DB related packages) or when I'm too lazy to troubleshoot makepkg failures.

I have done the ./configure. make. make install method for years. Coupled with rpm2tgz this was all there was. I learned how to used Sbopkg and liked it until I tried sboui. Sboui does dependencies too and makes my life easy these days. It is my computer and nobody else cares to use it or to use Linux so I use what makes me happy.

EDIT - Some software from trusted 3rd party sources come from Alien Bob and ruario are in my computer as well

3 members found this post helpful.

I use any method hat provides a formally good Slackware package, i.e. one that can be handled by {install,remove,upgrade}pkg, and try to check that the package won't override existing files, for instance.

If I package myself, of course I first use the tools needed to configure and build from the source tree, which I generally do first in a temp directory. But I never install directly, always with DESTDIR=<root of package tree>, using fakeroot 99% of the time (i.e. unless it be not possible) to be Didier proof.

EDIT And if I occasionally use pip, this is always in virtualenv.

recently, i have been going through the exercise of creating my own repo of packages, built from SlackBuilds.org. I use idlemoor's excellent slackrepo. Here's a longer description of the process, if someone is interested:

https://slackalaxy.com/2018/09/09/ow...es-repository/

the reason is that I need to install quite a lot of stuff, and I do not want to compile it on my laptop.

2 members found this post helpful.

I generally (but not exclusively) do ‘make install’ (or equivalents) and redirect the output to a staged directory via the likes of DESTDIR. I then use a shell script I wrote about 6 years ago to simplify installation (+ tracking/removal). It is sort like, super basic package management. I still use some Slackbuilds, particularly those built by others but for the most part I gave up creating new ones for myself.

I do it this way because I can knock up “BUILD” file for my pseudo package management system more quickly/easily than a SlackBuild, since the main script itself has most of the boilerplate code included (fetching/unpacking source, setting [root] file ownership, compressing man pages, stripping binaries, tracking file locations, etc.). It also has the advantage (for me), that it is distro independent. While I am primarily a Slackware user, I do frequently have to work with a range of distros. Since my script has no major dependencies outside of a typical Linux build environment, I can just re-use the BUILD file no matter what distro I am working on. The only thing I need to do first is to ensure that a suitable build/dev tools are installed.

As examples, here are a couple of BUILD files for some compressors I use for certain tasks:

Yes, these are cherry-picked, really basic examples and clearly more complex applications need more work (as they would to create a SlackBuild) but they show how simple things can be and I am sure most people probably appreciate that I likely spent less time knocking them up than the maintainers of their respective SBo equivalents. Plus, no need to make multiple packaging scripts (SlackBuild, PKGBUILD, .spec file, etc.) to work with a range of distros. On the flip side I realise don't get the various advantages that native packages bring (not least, integration with other distro tools) but for my own use cases I normally am happy with the compromise. I am generally only adding small simple packages this way and if my own tool is not good enough for a particular use case, I could always knock up a native package.


P.S. If the style of these these BUILD files look familiar, yes… I took inspiration from things like Arch's PKGBUILDs.

1 members found this post helpful.

I gave up watching it after the second obvious spelling mistake. I think they could have prepared better and done some editing. It was painful to watch/listen to and I couldn't see that I would learn anything from it personally.

Still… on the plus side I do appreciate that they used Slackware. Keeps the name out there.

2 members found this post helpful.

In theory, is there any reason why you couldn't install Slackware's pkgtools on another distro and then use SlackBuild scripts for custom packages?

1 members found this post helpful.