How do you choose to install third party packages?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So, since I already made a post here. Can someone sum up the methods mentioned in this post already? It would be nice to see all the possible options in the same list/post. I'm new to all of those other methods, and I might explore some of them at a later point.
I think most use cases can be summed up with:
Manual - ./configure, make, make install
Creating your own scripts to automate building
Using other's scripts (like from SlackBuilds.org)
Using tools to handle scripts and/or dependencies automatically (sbopkg, sboui, sbotools, slackrepo, etc)
Manually using 3rd-party pre-compiled repos (Alien Bob, SlackOnly, etc)
Using automated tools to work with 3rd-party pre-compiled repos (slackpkg+, slapt-get, etc)
I've come to appreciate su -c "", since I had a habit of forgetting to exit root terminal.
Same here. I use su -c most often when needing to run something as root. I tried sudo briefly but it would prompt for the password at every command, so for me it was no different than su -c. In Fluxbox I rarely load kde stuff so rather than waiting for kdesu to load I found ktss for those cases.
Quote:
Originally Posted by bassmadrigal
Sure, ./configure, make, and make install might be "simple" in creating the package, but not nearly as easy if you want to upgrade/remove/manage a package. That is when using package management tools make it much easier. Plus, SlackBuilds allow you to easily do reproducible builds. I don't know how many times in the early days of my Slackware usage that I would be compiling ffmpeg and mplayer. Those require quite the ./configure options due to many of the options not being auto-detected. Putting all those options in a script ensure I can compile it the same way when an upgrade comes along.
...
Some Slackware users will undoubtedly prefer the manual method of things, while others prefer to have other programs do the heavy lifting. I've had my experience doing things the manual way, but I tend to value my time more now than I did when I was younger. I just don't have the time to compile everything for ffmpeg and mplayer from scratch (and certainly not keeping up with their development versions as I did back in the day). I use tools that make my life easier, but still allows tweaking when needed. If I need to install a program and a SlackBuild isn't available, I'll create my own SlackBuild and submit it to SBo so others can benefit from it.
I know they are, but I doubt it's worth mentioning sudo everytime you talk about using root. I know it annoys me, and probably others too. I'm sure if a Slackware user has wanted to and managed to install and setup sudo on his system, he is probably capable of using sudo when necessary.
sudo is installed by default on Slackware. I'm not sure why the mere mention of a command would annoy someone. It certainly didn't annoy me.
sudo will certainly annoy the user who doesn't (sometimes refuses to) realize that in Slackware, for some specific operations, the root environment is required (especially the PATH).
But then I forgot all my knowledge about sudo, proof in a recent thread, not sure what to make of sudo nowadays (no use / no scenario).
What I'd suggest to the sudo "addicts" or better said su - "deniers", or maybe lazy admins that are afraid to forget the root console active is to try using:
The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The security policy shall initialize the environment to a minimal set of variables, similar to what is present when a user logs in. The Command Environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use.
Just spent some time watching the beginning of the youtube video Lysander666 presented in the first post and I instantly remembered why I use the root account (environment) for the whole installation process from the very beginning, including unpacking the source code.
Now I don't know who this serge is, my respect for him for investing the time in teaching Linux, but in my opinion, from an instructional POV under Slackware, he started wrong and because of this he made afterwards a second mistake with su (without -).
- minute 3:26 - the configure script is launched as non-root. Might get into trouble for not finding some required binaries that are only available in the root user PATH and I do remember that some configure scripts were checking if they were launched as a non-root user and created makefiles that install into $HOME, might get around the latter by always specifying --prefix=
- minute 6:55 - instructs to su without -, just to avoid changing the directory, bad practice under Slackware
My advice, if you go for a manual build, (double)check the sources of your application, download the archive, switch to root ( su - ) and stay as root in the root environment until you finish the compilation, packaging and installation.
- minute 3:26 - the configure script is launched as non-root. Might get into trouble for not finding some required binaries that are only available in the root user PATH and I do remember that some configure scripts were checking if they were launched as a non-root user and created makefiles that install into $HOME, might get around the latter by always specifying --prefix=
Never had trouble compiling stuff as an unprivileged user. In fact, I'd be dubious about installing anything which refuses to compile under a non-root account.
Quote:
Originally Posted by abga
- minute 6:55 - instructs to su without -, just to avoid changing the directory, bad practice under Slackware
Why is this bad? Why do you need root's whole environment just to move some files around?
Never had trouble compiling stuff as an unprivileged user. In fact, I'd be dubious about installing anything which refuses to compile under a non-root account.
I was focusing on the configuration script (+some other automated operations) not on the compilation and also focusing on the specific Slackware root environment. (some other distros might have the same PATH for all users)
Quote:
Originally Posted by rkelsen
Why is this bad? Why do you need root's whole environment just to move some files around?
Again, in the context "bad practice under Slackware". People who are new/learning Slackware might remember a simple su
Since I advised about always using the root environment when manually building apps, I just felt the need to cover the situation in which the compilation will take a long time and the root console is not recommended to be left open. In this case just use nohup for the make (or build script) and close/exit the terminal/shell:
Code:
nohup make 2>&1 | tee compilation.log &
You can tail the compilation.log from a user terminal that you can leave open. Not sure how secure that is, given the abundance of privilege escalation bugs/exploits, I never do that.
(Lecture) https://payatu.com/guide-linux-privilege-escalation/
I was focusing on the configuration script (+some other automated operations) not on the compilation and also focusing on the specific Slackware root environment.
I had always read it's best to compile apps as a regular user and then install them as root (if desired). I did this way back in the early 10.x versions of Slackware all the way until I found out about SlackBuilds (I kept all my source and compiled programs in ~/program-downloads/ as my regular user and did all compilations as that regular user and ran make install as root). I don't remember ever running into limitations because I wasn't doing it as root. And configure scripts generally don't look for binary executables... they'll look for libs or .pc files that will show them where to look for files.
I did many times, messed up builds because I wasn't root, but in the "far" past and learning the lesson I never attempted commencing any build as non-root ever since, thus, without the experience of building as non-root I cannot deny that you won't get into troubles with the recent design of the configuration scripts. However, as rkelsen says, it doesn't make any difference for me always building in the root environment instead of a non-privileged user environment under Slackware, at least I go the safe way and never fail. I do however take great care about the source and the method from where I take the source files, making sure they're not tampered (always double-checking).
Search common directories (that `make install` is likely to have placed files into) for all file types except directories, that were created (modified or changed) within the last 5 minutes and print them into a log file.
You can alter the directories as you see fit but don't just use / because then you will find stuff in a bunch of other subdirectories that might have been written to within that time frame (e.g. /home, /tmp, etc.). Sticking to common install directories will lessen the chance of false positives.
You could also alter the time but so long as you issue this immediately after `make install`, 5 minutes (or less) should be fine, given that I have never seen a `make install` command take that long.
Quote:
Originally Posted by ruario
Code:
xargs -d\\n rm -v < program-name_files.log
Separate the log contents by new lines and pass these as arguments to the remove command verbosely.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
