The question was addressed to ruario, however my answer is: one of the main purposes of pkgtools is to maintain the packages database in /var/log (or more recently in /var/lib) which is found only in Slackware and derivatives. Which also means installing pkgtools in alien distros. Not worth the hassle, I guess.

1 members found this post helpful.

Ah, I didn't know that.

Yes and I have done it in the past but it requires a few patches to Pkgtools to make them work on other distros because of differences in paths, some tool locations, and a few other things. I stopped maintaining patches for it some time back, though it would likely be easier now because you no longer need tar-1.13.

Another option (and again something I have tried in the past) is to compile spkg (an alternative implementation of installpkg/upgradepkg/removepkg) and pair it with something that can make Slackware packages (like this) but you still have to create SlackBuild files (which contain a lot of bolierplate code). Now you could use slkbuild as well (and I also did that for a while) but in the end I figured it was better to just simplify this whole thing down.

That is why I made my own system, which is just a shell script that I can quickly copy to any target machine and (once I have a build environment installed) I am up and running and ready to track my installs.

Here is an example video of me compiling, installing, using and removing “afio” on OpenSUSE using my own system (afio is interesting because it is a great tool but distros often don't package it because of licensing issues).

https://createpkg.r0.nz/afio-install...epkg-suse.webm

P.S. I don't make the BUILD file then and there but rather copy it from a little personal repository of BUILD files I have on Github.

Look I even found an old thread from seven years back, where talk about doing exactly this!

It was only 1-2 years ago I started using SlackBuilds.org. When I started with Slackware I did everything manually with configure + make and learned quickly about dependency hell. Later I found the third party packages from sources such as linuxpackages and slacky.it...what a mess that made! Another mess was when I mixed packages from -current with 14.2. Now I use SlackBuilds first or I compile manually. The only third party packages I still use are from AlienBob and jaos. jaos made slapt-get and gslapt, which I like for installing updates.

I was just going to say that my choices of tools are probably a little unusual:

1. slapt-get/gslapt for official packages and Alien Bob (mainly multilib and a couple other things)
2. sboui for most other third party software
3. My own SlackBuilds for personal software and other things not found in 1 and 2.

But maybe slapt-get/gslapt isn't actually that unusual. It's nice for desktop use on a -stable release, but I don't think I would use it for -current. I still use slackpkg for some features that slapt-get lacks, anyway.

I use slapt-get with my own repo, since I install different things on my different computers and I need dependencies resolution.

I still often use the old school method directly especially when the specific package has a lot of ./configure options, however I used to rely on "Checkinstall" and now "makepkg" so that an uninstall is less difficult than when "make install" is employed. If a package is straightforward and has few configure options I tend to get lazy and rely on Slackbuilds.org and unfortunately it seems my laziness increases every year

To be strict and honest I would have to neglect all third party repos. No matter binaries or kind of slackbuilds. Build only from sources on machine which will be devoted only for this solely purpose. After number of test I would decide install or not. But this means of course a lot of study, perhaps self-study. The attitude 'try to solve this by you-own before asking for help', willingness to experiment, willingness to pay price for failures. The understanding that most things are complex despite all-around opinions that 'they should be simple'. They are only peeple so eager to convince others about 'simplicity'. But all this means lot of work but also lot of satisfaction. And of course lot of fun. But having said all this my daily routine is just to use slackbuilds for relatively small builds - and binaries packages for too large builds - I cannot afford due to system requirements limitations. For slackbuilds I use my own script - which is just abstraction of many years by-hand installation procedure. For binaries I am looking at AlienBob repo, also Salix repo, and others repos I can find and they are enough trustworthy.

1 members found this post helpful.

Cringe!!!

Nobody use ./configure, make, make install anymore?? wtf did I miss. I even saw someone use sudo here somewhere.. Yuk!

How about:
1. ./configure 2>&1 | tee configure.log
2. make -j3 2>&1 | tee make.log
3. make install 2>&1 | tee make_install.log

cp *.log /root/installs/logs/prog-xyz/
cp *sources.whatever /usr/src/repo/source/prog-xyz

Depending on what and how, "third-party" stuff might/is suppose to go into /opt..

I like to use scripts to build things so that I can remember what configure options, patches, etc. I used. And once you do that, you might as well put a makepkg command at the end and build a proper Slackware package.

I only install a hand full of 3rd party apps, which is mostly if not all, already on slackbuilds. SBOtools takes care of that.though now that I put a little more thought into it, their is one I am now using e16 , which I don't think anyone else is really using anymore besides me, and the slackbuild itself has three different sources to it. the wm/st themes and docs, where after opening it up and looking at it, I figured why not add the epplets to the script.

After after modifying a piece of code in one of the files for the epplets to get them to "work" with wifi instead of eth0 which I do not use. I used the slackbuild script to do ll of that in one movement putting all of it into one package so it works seamlessly together being all placed into the same like directory structure. /usr

when working on modifying code it does make it easier to install and try it out, then remove it if needed. over using the ./program name in the terminal too.

as far as using a package manager in slack, just using the configure, make, make install still works just fine. Only one either needs to keep the source code handy, or has to get the source again and hope who ever wrote it put in a uninstall to remove everything it installed, if needed.

with the 2>&1 | tee file you get the log. I mean, you could even go as far as to save the relevant section of bash_history if need be.

I watched this almost all the way through. I was interested in sbopkg and sbotools, I've never used them before. Made it as far as the beginning part of sbotools, just couldn't take it anymore. I thought the video would be more of a turn off for someone thinking of using Slackware. Well that's my two cents. I don't think I'll switching to sbopkg or spobtools either.


The old fashion way, via a SlackBuild script. I like to call third party packages, non-slack packages.

I use slackpkg via slackpkg+ along with pkgtools to manages my non-slack packages.

I've gone though several build environments. This is what I have now:
I have a single template.SlackBuld that has just about everything that is needed for creating a SlackBuild script. My scripts do the usual things as a SBo or Slackware SlackBuild. They also download the source(s), create the slack-desc and doinst.sh. The template has a configure, build and install section for autotools, meson, cmake, qmake, perl, python. My scripts also log the outputs. All of my scripts have a header (dependencies, reason I installed it), change log and error checking. Almost all scripts require bash 4.

In using a script with a new package I use the script to just download the source then look it over in particular to see what build system is needed and possible configure options. I then proceed to build the package, but place an 'exit' after the last step of the configure, build and install process to see what needs to be done to finish creating the package. The script will abort if the configure or build steps fail, the log comes in handy to figure out why. If I am thinking of added a new program, I primarily use the source/site to determine dependencies, but SBo or Ponces/slackbuilds come in handy also. I occasionally use slackfinder as a reference.

I build my own because sometimes the dependencies I want or need don't match SBo, plus I sometimes want other build options. I like to combine things, as an example my flashplayer-plugin.SlackBuild checks for multilib and builds the compat32 package, tesseract.SlackBuild also installs training data files. I prefer not to put put anything in /usr/local/ or /opt/ (virtualbox blob being the exception) so my scripts take care of that (google-earth-pro for example). I also would rather not build in /tmp. I have a 50G root and occasionally building in /tmp has filled it up, even at 45% free. My /home is 866G with 52% free. It also very satisfying build your own packages. That is probably the number one reason I build my own. One particularly satisfying build was for perl-finance-quote used with gnucash, 80 perl dependencies. I have learned a lot by building my own, finding patches for example, learning were to look first, compile, configure options, etc. plus getting pretty good at bash, don't have to look things up as often now.

I use a few non-slack programs from Alien Bob (calibre, chromium, chromium-pepperflash-plugin, dropbox-client, ffmpeg, gcc5, handbrake, libreoffice, openjdk, steamclient, vlc). There is a slackbuilds/<package> for each. In each directory I have mirror-alien-build.sh and a dl_packages.sh script. If the build fails and I can't figure it out, I just download the package. I recently changed this and now use slackpkg+ to handle Alien Bob's packages. I'm leaving the directories in place for two reasons, I am working on building on my own and I may go back to putting the packages in there again to be part of my local repository. Simplifies things across my other Slackware installs (download once).

@zeebra You could if you like making it hard for yourself for no good reason. If you are going to that much trouble creating all these logs, just make a package. Your suggestion is slower, more effort and appears to have no discernible advantages. Also while /opt is a fine place, /usr/local is also completely acceptable for self compiled packages (outside of packaging) and involves less hassle to get system integration.

P.S. You provided no install command at all. In your example, you simply compiled. With your ‘method’, is one expected to then also copy all the files into place? If you are trying to look clever, it ain't working…