Questions on packaging in Slackware
 

Hi, I'm still trying to get to grips with the whole Linux packaging system thing and I'd just like to clear up a few things to make sure I get all this right before moving on and thinking I get it.

If I've gotten anything wrong, please feel free to correct me. :)
As I understand it, it's always desirable when installing software, to install it as a package rather than manually installing the binaries. This allows the user to use their distro's package managing system to keep track of all the directories that software sticks its fingers into, so its files can be removed or edited when uninstalling or updating said software easily.

But sometimes, if for some reason, say, a piece of software uses a non-standard build system, it can be difficult to package, and so it is encouraged that the user manually install the source not as a package but on its own. As I understand it, in such circumstances, the user wouldn't be able to reliably uninstall all the application's files unless they studied the install script and made note of every directory it touched or patched the script so it then includes a reliable uninstall function if it does not already have one.

So when would a user use Check install? seeing as it requires a ./configure file, but surely if a ./configure file is present, the user would be able to package it the standard way?

And in reading the documentation available fromslackware's documentation site
I don't think I know how to actually perform steps 2 and 3. Say for example, that for whatever reason, I wanted to install something like Audacity, from source. how would I perform steps 2 and 3 as listed above for creating a package for it?

And when it comes to installing Java applications, do they not need to be packaged? From the few semi-popular java applications I've seen, none of them seem to have packages available on slackbuilds.org but from their respective websites, to me, a newb, at least, it looks like it's just as simple as downloading the .jar for an installer and running it. In situations like that, would there ever be reason to build from source instead?

No, CheckInstall doesn't require ./configure at all. All it requires is install target to be present in the Makefile. You then run checkinstall instead of make install.

Moreover, even if there is no install target in the Makefile, you can successfully run checkinstall by specifying the actual install command as argument:

Check 'slacktrack' in the 'd' package series - this is what it was made for.

So, what you've stated is the way some people feel software should be installed with Slackware, but ultimately, it's your system and your choice.

Personally, I prefer to have packages for (almost) everything. I generally don't like using install scripts provided by manufacturers, since it won't result in a Slackware package that is tracked by pkgtool. Many of those installer scripts are quite powerful and very capable of removing themselves from the system (I believe virtualbox and nvidia fall into this category), but others can make changes to your main system without you realizing it and can cause breakage (however, it's been a long time since I remember hearing of issues like this).

If I find I need something on SBo that isn't already there, I will usually write up a SlackBuild and submit it, because I imagine others will come across it at some point.

If a program is provided as a binary .deb or .rpm package, many times you can deconstruct that and rebuild it into a Slackware package. This is done on SBo occasionally. I did it for a discord SlackBuild since the program is closed source and they only provide pre-built packages. I just took one of those packages and extracted it to put it in the structure that Slackware needs for a Slackware package.

The program you were trying to do on your other thread is lacking a standard build system (autotools, cmake, python, etc). This makes a SlackBuild more complicated. You could either try to replicate what their install script does as a SlackBuild or dig through the script and see if there's ways to run that, but tweak it to give you the ability to package things up when it's finished.

There are several programs that can help generate a Slackware package without having a SlackBuild. That is where things like checkinstall, slacktrack, src2pkg, and more come into play. They will compile the software and hopefully result in a proper SlackBuild.

I want to learn how to be able to do this myself, but the only software I can think of right now that I'd like to install are all either available on SBo already or are Java applications which lead me to asking more specific question to do with the relationship between packaging and Java applications. For instance, for I2P, they list on their downloads page; an Ubuntu package, a Debian package and a .jar file for an installer and the source itself as a .tar.bz2 file. I take it then that the two best options would be either the .jar installer or compiling the source? On their Github page it says that to build the source, it uses the Ant build system and that in order to install it, the user just needs to run ant pkg which will then give you the installer but being someone who has, as of writing this, 0 experience with apache-ant let alone any other build system, surely it's not as easy as entering a single command like that?

sidenote: Interesting that you're the one who made the Discord SlackBuild, i was just looking at it earlier today and I was thinking of posting about it at some point but thought it wouldn't warrant its own thread. The source on slackbuilds.org, is that only for 64-bit systems? I run a 32-bit system so was wondering if it's still possible for me to run discord? Or would I have to get an Ubuntu package and convert that?

I'm not familiar with ant as well, but you could use SBo's reverse dependency feature under Advanced Search to see what other projects require apache-ant, which may help give you an idea on how to better use it.

https://slackbuilds.org/advsearch.ph...&stype=revdep1

You don't have to necessarily build it from source and you can potentially try and repackage the provided .deb file. It's what I do with discord (which is because they don't provide source, but others do repackaging just for simplicity (look at the repackaging options for libreoffce vs building with LibreOffice).

Last I looked, Discord did not provide a 32bit version. If they do now have that, I'd be happy to add support for it, but I didn't see a sign of it on their website.

You might find src2pkg interesting. (Download link is here.)

Also keep in mind /usr/local and /opt both exist more or less for these cases.

I don't usually use /usr/local because there is a sort of assumption you are going to have a traditional set of shared directories under that: bin lib etc

/opt in strict LFS terms this is a bit of an abuse of opt but a lot of things do let you set an install path even if they don't use the traditional autotools install process. You can create directories under /opt per application you install there, you know they are not part of slackware, not part of package etc. Its good for "stand alone stuff".

/opt/Google\ Earth
/opt/Aptana\ Studio

etc.