you monster

4 members found this post helpful.

Ok, well, that will work under many circumstances, but not if you build two things in a short span of time, let's say a dependency. And is it really a safe way to do things? I mean, to me it seems that things could go wrong by using this method.

With configure, make, make install logs you will have a very precise overview. Sure, it will contain alot of garble as well, and it will be a very manual process to deal with it IF you need to say remove everything in there. But with grep and other tools you can modify those logs easily and also find more exact things you are looking for, if there is perhaps 1 file or parts of that program that you need to know more details about.

Anyways, I'm back to Slackware after years of using other distroes with pretty much build --automation --tools. While this is good for everyday use and "just works", it really slows down the learning process. Which is probably the reason I did not understand your bash command in the first place. I need to get into the nitty gritty, and I think manual labour is the way to go for that. While that might be personal to me, I hardly think saving logfiles when doing configure, make && make install is something that should be advised against. For me it seems like a good idea, something I want to work into my routine when compiling and building from source.

I guess mentioning /opt was pretty stupid and unecessary, but I do want to start using /opt correctly even though it might seem somewhat of an obscure concept and generally not used at all. I just thought it was worth mentioning. I'm also trying to figure out a bit about how to build a virtual environment and jail and such things, and I think a thought I had was to build one in /opt and integrate some non "standalone" software into this kind of environment. System integration as you mentioned is the point exactly, to avoid system integration.

One good example could be Firefox.

Anyways, I'm here to learn, but I'm not a newbie. But I think the last version of Slackware that I used before my current 14.2 version was probably 11.1. And my first ever distro was Slackware, somewhere around 8.0 or 8.1.


Gimme -vv!

IMHO, the best way is to create a SlackBuild and share it with the community, by submitting it to SBo. In this way, it will pass a certain quality check and other users will benefit.

PS: zeebra, how much of additional software do you install?

5 mins is an example. As I already explained, you can knock it down further if you compile quickly several packages. It is no big deal, not least because I also specifically said that you should review the log and I think that doing so would make it fairly obvious what happened if you had the timing off, at which point you would adjust it and make a new log. This is still a hell of a lot easier than manually going through the type of log you suggested.

Also, this is just one example. If you want another way off the top of my head, here you go. Do a find with no `-cmin x` (and thus listing all files) just before the `make install` (and save that to a file), then again just afterwards (and save to file). Then diff these two and you have a listing of all installed files, e.g.

P.S. I also already gave you another even better example using a staging directory, which is what I actually do (when not making a Slackware package).

You didn't ask me but I will give you my answer. On the machine I am using now, I currently have 32 packages installed via the type of logging tricks I have mentioned in this thread, consisting of 2696 files. I can tell you this easily because of the types of logs I create. I can also selectively uninstall any one of them with a single command.

[EDIT 1]: I do this because it gives me some of the advantages of a making a native package, using a distro agnostic method. That is something that is useful to me, though I appreciate that it probably does not matter to most people. If you are a pure Slackware user, SlackBuilds are clearly the way to go.

[EDIT 2]: In fact I could take that further and say that learning how to make packages in whatever your distro of choice is, is always a highly valuable skill. Native packages will always have a number of advantages.

1 members found this post helpful.

I noticed straight away that 'sysconfigdir' was mispelled 'syconfigdir' and it was painful waiting for him to correct it. However, they did say at the end of the video that they intentionally kept those parts in there to show what a difference a typo can make.... just as zeebra says:

I was wondering that too. I think if I was trying to get into Slackware and I watched the video I would find it very dry and it would possibly even put me off. The main issue is that Serge [I also don't know who he is] doesn't explain each command as he's giving it, it's just parrot fashion - this command, then that, then that.

I think the video would best suit someone who has started using Slackware - they've installed it, they've already installed and used a few third-party packages and they want to get up to cruising altitude.

They said they might do a part 3. It may be in the interests of the video-makers for them to take a look at this thread before they do so, there's some great advice in here.

While we are here and for future reference for anyone stumbling across this thread after doing a `make install` (with no logging) and wondering how to clean up, here is another neat `find` trick.

You can use `find` to locate files associated with a package, if you know just one of the files within the package. For example, say I have zstd installed and I want to remove it and all of its associated files. First I note the timestamp for ‘Change’ (inode data modification) on the main executable.

Note: Change in this case includes any of the following system calls: chmod, chown, link, mknod, rename, unlink, utimes or write. So unless you have done any of these on the files again after install, it will effectively be the installation time. Furthermore ‘Change’ (in this instance) is a better timestamp than ‘Modify’ because when files are copied into place, their modification timestamp is sometimes reset to that of when the file was last edited by the package maintainer and this could be long in the past (this is particularly true of doc files).

Ok, this file had a Change timestamp of (roughly) ‘2018-12-13 10:43:04 +0100’. If I take 3 minutes before this time (2018-12-13 10:40:04 +0100) and 3 minutes after (2018-12-13 10:46:04 +0100), I now have a nice range when the rest of the files are likely to have been installed.

I can then construct a find command based on this information to find files (excluding directories for the reasons I mentioned previously) from the same time period, e.g.

Which on my system gives me:

If I am happy with the result, I can then modify the above command to remove these, like so:

Oh and you will want to run those commands as root (or prefaced with `sudo`). Sorry… couldn't resist!

P.S. All my notes about tracking files associated with manual source installs are now collated in this ‘gist’ on Github

2 members found this post helpful.

This is ofcourse a good point. Adding to and doing things in a community is ofcourse a very integral part of the whole experience.

Well, as I said, I just got back to Slackware, so I have not really installed much software at all. But, what I am trying to do is to do everything from the lowest point up, I'm not making any shortcuts etc.. So, sure, my way might be different, but I am sure many hardcore Slackers also follow this kind of path. So, the first thing I found out when getting back, after learning a few things and configuring and fixing some other things; when I finally started installing some software, I realised I need to keep track of what I am doing, thus the whole log thing was something that I added and worked into my routines.

I installed Slackware on a new laptop, and this is basically a trial run, and thus far I have run it with ifconfig all down. So I am literally doing everything manually, including fetching packages via a USB.

I am trying to learn certain things in an orderly fashion, to upgrade my knowledge and learn new things. I am using this laptop and my current Slackware for that purpose. I am trying to build a set of best practices that I can implement when I finally build my productive system.

How much software I will need on that productive system is quite unclear, but what I imagine doing is building a seperate tree for all these things and run them in various jails under some kind of environment other than my main system. At least this is what I am trying to figure out, and no, I am not going to take the easy route there either. Currently I am working on a way to adapt and integrate SeLinux into my current Slackware version, so you can possibly understand what a stupidly complicated route I am taking. All in good fun and spirit though.

But anyways, I am writing this from another productive system, so no need to worry. I just want to make things perfect for the next step of my GNU/Linux experience, and part of that is to learn much more indepth a list of things I have scribbled down, to reach a level where I can manipulate the whole system, do everything manually but efficient and adapt it to my hearts desires.

Ps. I can imagine Enlightenment is something that I will want to install on my future productive system (manually ofcourse). Additionally I can imagine I will be experimenting with Wayland in some kind of virtual environment too. So, yes, some amount of software just from those 2.

Great list, thanks. So, from just a few months of rejoining Slackware, my impression is that the "big" one is Slackbuilds. This is the big new thing that I have missed and the route that many seem to take. This is a common topic on Slackware threads and information pages etc. It's pretty clear what it is..

But, I want to ask you (or someone else) another favour if you'd please break down those other tools in bold. Various of those tools have been mentioned in this thread, and I think I've seen them around elsewhere to. So, what is the difference between those? And where do we find them? Just very briefly in a similar list if you would kindly please.

Thanks.

sbopkg is an interface to SBo. It has a very similar look and feel to pkgtool. It does not resolve dependency directly, rather you can generated the so called build queues, by a script called sqg, which is included. If you want to generate queues for everything at SBO, you run sqg -a. Be patient.

sboui is a tool with a look and feel similar to midnight commander. It has its own capability to manage stuff from SBo, and in addition it can 'drive' other tools such as sbopkg and sbotools.

sbotools is a suite of commands that have a ports-like feel. They directly resolve dependencies.

slackrepo is different. It is a program very useful to create your own repository of precompiled packages, for example from SBo. I use this, as I have explained in my first post in this thread. slackrepo is meant to be used in a clean environment. This means, you should dedicate a virtual machine only to building packages. When you create a package, slackrepo will build its dependencies and then, when everything is completed and packages are ready, slackrepo will uninstall them, to keep your system clean. So when you build something else, only its own, required dependencies will be present at build time.

5 members found this post helpful.

I will install pre-built third party packages from trusted sources like Eric and Robby. I'll also use build scripts from the good people at SBo.

1 members found this post helpful.

This is part of the beauty of using the package tools within Slackware. When you use make install using the DESTDIR option, it will run an "install", but place all files in the folder you specify for DESTDIR. This is the exact folder/file structure that would've been placed in your normal filesystem. When you run makepkg, it basically tars up all the files and compresses them using whatever file extension you specify (the two most common, tgz and txz provide gzipped packages and xz zipped packages respectively). When you using installpkg/upgradepkg, it will basically unzip those files in the root of the filesystem and make a log stored in /var/log/package/ under the file name of the package (note, the location has been changed in -current to /var/lib/pkgtools/packages/). This allows removepkg to verify whether those files exist in any other programs to ensure you aren't removing a file a program depends on.

pkgtools basically implemented your logs for the installing aspect and ties it in with all packages on the system.

Using more automated processes definitely does slow down the learning process. I understand so much of the packaging system because I did it the old way for so long (which caused me to break my system multiple times). I don't blame you at all for wanting to stay away from the automated aspects so you can learn things better. I will say I doubt you'll have much of a need of ./configure and make logs, but the make install could be helpful. But if you already know the basics of compiling, you can then make your own basic SlackBuilds, and you can tweak and change things as needed. I provided this basic SlackBuild in another thread, and just for kicks, I added logging for the ./configure, make, and make installs and stored them in a doc directory for that program.

So, /opt/ is kinda an interesting directory. If you are to build Firefox from scratch, /usr/ or /usr/local/ would be a better place for it since it integrates cleanly into the filesystem standards, but if you were to download a prebuilt binary, /opt/ would be a much better place for that. If you want to learn more about how the directories should be used, have a look at the Filesystem Hierarchy Standards (FHS). /usr/ is for packages that use the defined folders like /usr/lib/, /usr/share/, /usr/bin/, etc. For the packages that don't or are pretty much self-contained, /opt/ is a much better place. You'll see this location used with many pre-compiled binaries on SlackBuilds.org (commonly called SBo).

Learning is great! Don't let the suggestions here tell you otherwise. When you have a better understanding of how things work, you have a better understanding of how to fix things when they ultimately go wrong. And sometimes fixing things (without reinstalling) will teach you more than you would've had you not broken it. I am really grateful for all the time I spent learning the ins and outs of compiling, dependencies, packaging, and SlackBuilds. But now that I have that knowledge, I've found it is not worth my time to do things manually.

I love SBo and what it has provided to Slackware users. We get a consistently great repo of scripts that can be used to build software, but also gives us the flexibility that Slackware is known for. The SlackBuilds tend to have sane defaults, like Slackware, but we can choose our own dependencies (either removing "required" ones the maintainer specified or adding our own optional dependencies), add our own options, and you could even tweak the scripts to add extra logging. While SBo has a decent number of packages available, I have found at times that something I'm interested in isn't available. When this happens, I will generate a SlackBuild myself and then submit it so others can benefit. This minimizes duplicated effort.

I love SlackBuilds. They really are a great way to build software. SlackBuilds.org (SBo) modeled their templates directly from the SlackBuilds that Pat uses to build Slackware (you can find those in the source/ folder of your favorite mirror). I love SBo and what it has provided to Slackware users. We get a consistently great repo of scripts that can be used to build software, but also gives us the flexibility that Slackware is known for. The SlackBuilds tend to have sane defaults, like Slackware, but we can choose our own dependencies (either removing "required" ones the maintainer specified or adding our own optional dependencies), add our own options, and you could even tweak the scripts to add extra logging. While SBo has a decent number of packages available, I have found at times that something I'm interested in isn't available. When this happens, I will generate a SlackBuild myself and then submit it so others can benefit. This minimizes duplicated effort.

solarfields did a better job than I probably would've, so I would refer to his list. However, because you have the interest to learn, I would avoid using the automated tools until you understand how SBo handles packages, including dependencies (and dependencies of dependencies as they can get quite deep at times). They have a great HOWTO. The big things are to read the README and to check for dependencies. Both of these are easily viewable on SBo, but if you download the files, there will be a README file and a $PRGNAM.info file that will list the direct dependencies. Now, if any of those dependencies have their own dependencies, it will not be listed on the main file (to prevent duplication), so you may need to go several layers deep to get all dependencies.

My only minor nitpick with this description is that it will actually do all building in a chroot that is mounted over the main system. This ensures the main system remains clean even if programs decide to modify things they aren't supposed to or place files outside of DESTDIR where makepkg can't track them. When everything is done, rather than uninstalling packages, it simply unmounts the chroot and then deletes the folder containing the changes to the filesystem.

You might have already known this and were just simplifying it for your explanation. If so, I apologize.

Sorry for my novel

5 members found this post helpful.

I did not know this. Thank you for the clarification!

1 members found this post helpful.

One thing that was missing from the above two posts is a tool that Richard Cranium mentioned.

src2pkg is something I have seen many Slackers mention using. It automates turning a source package into a Slackware package (amongst other things) ‘automagically’. The author Gilbert Ashley (gnashley) is also a regular of these forums, and he is both very knowledgeable and very helpful.

If you are avoiding automation as a way to learn you might want to skip it initially, but keep it in the back of your mind as it could come in very handy in the future.

3 members found this post helpful.

Yes. Src2pkg is great. I used it before i decided to learn how slackbuilds work.