I just remembered another really nice little tool that with automates tracking and helps with Slackware package creation. It was created by Slackware contributor Stuart Winter (drmozes) and is included in Slackware by default: slacktrack

1 members found this post helpful.

I turned this trick into a basic script that I have called f2sb (forgot to slackbuild). Handy in situations where you already installed something manually and later regret this and wish you had made a package after all.

The script will convert your already installed (and untracked) files into a package that you can then install over the top and thus (if you wish) also cleanly uninstall using removepkg. I hope it helps someone in the future.

3 members found this post helpful.

Yep, it is easier now. As a test, I quickly patched -current versions of installpkg, makepkg, removepkg and upgradepkg. I just needed to switch the scripts to require bash since they contain some bashisms (some distros use dash as sh), handle a few hardcoded paths, flip around some find options and I also removed a couple of warnings from makepkg that would not make sense on other distros.

With these few tweaks you could place installpkg, makepkg, removepkg and upgradepkg into /usr/local/sbin and use them as a secondary package manager for self compiled packages, thus avoiding the need to mess with rpm .spec files and other overly complex packaging systems.

Here are my patches if someone wants to try it out.

P.S. I am not planning on maintaining these as I already have my own system for cross distro "packages". I just did it as a little exercise to check how hard it would be (it isn't).

2 members found this post helpful.

Ok, so this thread is old, and I know it's inappropriate to reopen it. But is is also highly rated, so it might be useful for some people.

During my usual kind of experimentation I recently came across and installed a distro called GNU Guix (system), and one of the interesting things is that this is not actually primarily a distro, but a package manager that can in theory be added to any distro. The concept is fairly complex to understand, as it's not a normal package manager installing packages in a normal way, but rather in it's own kind of weird way. Trying the distro Guix and how the package manager works within it was quite an interesting thing.
Installing (deploying rather) and removing packages is super easy, but coming to terms with how/where it is installed exactly it slightly more challenging. I guess I have to spend more time looking into the details.. But.. It seems it is/could be a great tool for "deploying" some end user programs without complexity, but perhaps not so much for system software.

Anyways, I was wondering if anyone here has any experience with Guix on Slackware, and I wanted to mention it as an option to install third party software.

https://www.linuxquestions.org/quest...on-4175695567/
https://www.linuxquestions.org/quest...ix-4175438542/

My belief is: static binaries. I just heard of appimage. Darn snapd asked me to reboot MX with systemd
https://www.linuxquestions.org/quest...ge-4175649087/

I love puzzles: ddGoo'ing keywords

Yes, I already read that first link before posting here, thanks. But it's a good reference thread.

Yes, like most package managers it does that, but unlike them it has some kind of other way to install dependencies, and it's all installed in the same location (run/var or var/xx or some place). Seemingly not touching the rest of the system (or using only /usr/lib usr/share?). I couldn't quite figure out exactly what it did when I tested it, it was quite unusual and somewhat confusing.

Anyways, it seems like it could be a worthwhile way for some people to install third party software in Slackware.

Ps. I suggest you read the whole thread if you're missing the context

While I have benefited from the convenience of Slackbuilds, I do miss the early days when Checkinstall still worked properly. I recognize that it isn't awfully difficult to write a specific slackbuild script but it is more involved and less "hands on" than simply running "checkinstall" and dealing with any errors if and when they occurred. The advantage I see is the complete freedom to at least try to install anything for which you have source code. By depending on slackpackage repositories, inevitably since it is just easier, the one-size-fits-all software becomes favored via popularity and it becomes somewhat either more difficult or less desirable to seek and use "fringe" or more specific use case software.

An example is the application for audio playback that became so popular it was, IIRC, at one time default in Full Recommended Install, and I can't even recall it's name because what it did best was organize one's music collection which didn't matter much to me. I much prefer an app like Aqualung that is more focused on performance of the player, even including LADSPA plugins like various EQs and "Tube Warmth" processing support, obviously a niche use case. So I rely on it's own generic installer as I do with several other niche apps not popular enough to be included on sites like Slackbuilds.org.

I'm not complaining. I just wish something simple like Checkinstall was still in play and supported, but I suppose that's not the way Linux in general is evolving. Too bad.

Funny you mention that. I was "advised" to use checkinstall on Mageia recently. I don't remember the software or why, but I remember in the end I skipped using checkinstall and ended up using rpmbuild instead. As far as I understand it does basically the same thing that you describe checkinstall does, except it creates an rpm that you can use in whatever package management method.

Stable release 2009, ok, but it could still work just fine? It's probably quite a static program that doesn't need security updates or such things. Perhaps if it needs some care it might be possible for someone to take it under their wing and maintain it.

You're right, it does seem like a useful minimalistic tool.

rpmbuild is much more robust than checkinstall. See e.g. this answer @AskUbuntu or this old thread here at LQ.

By what standard do you claim rpmbuild is "much more robust than checkinstall"? I mean it is since rpmbuild is still maintained while checkinstall is not and checkinstall is by over a decade obsolete, but that doesn't mean there is some unredeemable value to something like checkinstall which basically is just a tracking "make install" that creates packages that can be managed. Certainly rpmbuild is better than checkinstall at building rpms but surely that has no bearing or use on Slackware.

I clicked your links (thank you, btw) and the one claim that it hosed one guy's boot drive I find rather unlikely if not ridiculous. I can see no manner in which "make install" for emacs would have any effect on boot therefore neither should checkinstall unless some really serious, really ignorant editing error was made that would force an include affecting boot.

I do not install third party packages. I make exceptions if:

• the source is available (upstream source plus script used for building)
• and I trust the packager
• and the build hae been done on a clean and full Slackware system, possibly with listed additional dependencies if they meet the same conditions.

Then I get and install the packages using slapt-get if possible, or just wget + pkgtools or spkg.

I'm new to Slackware, use Current.
I use sbotools, too dumb for old methods, I use sbotools:

sbosnap fetch
sbofind <package>
sboinstall <package>
sboupgrade --all

I use icewm, xfe, hexchat, numlockx, unclutter, neofetch, inxi, etc...
works fine...