LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   newb question - slackbuild packages - keep after install? (http://www.linuxquestions.org/questions/slackware-14/newb-question-slackbuild-packages-keep-after-install-4175451395/)

stringchopper 02-23-2013 08:47 AM

newb question - slackbuild packages - keep after install?
 
Hi all,

Do I need to keep slackbuild packages and scripts after doing the slackbuild and installpkg?

ie, would these be useful for restoring the system or upgrading kernels, etc.?

thanks, :)

GazL 02-23-2013 09:00 AM

It's a personal choice. You don't have to keep them around, but I like to as it can come in handy at times.
Unless you have need of the disks space for something else, why not keep them?

stringchopper 02-23-2013 09:13 AM

Quote:

Originally Posted by GazL (Post 4898160)
It's a personal choice. You don't have to keep them around, but I like to as it can come in handy at times.
Unless you have need of the disks space for something else, why not keep them?

Thanks for the reply. :)

So, if I have a problem and need to restore, or if I'm upgrading, isn't there another location with the built packages that would be better to keep / backup? Or would I have to rebuild everything with the scripts? For example, vlc was a bear to get up and running - no problems, but with all the dependencies, it was time-consuming to install from scripts.

Assuming there's another location(s) that I can backup and use to restore, what other reasons would these script packages come in handy?

Alien Bob 02-23-2013 09:44 AM

If you want to preserve packages in case you need them for a re-install then you can save them to any medium, like a USB stick.
If you ever want to upgrade to a newer version of Slackware, there is a possibility that you have to recompile some of the packages. In that case it is wise to keep the sources, SlackBuild scripts etc... but otherwise, it is OK to just keep the binary packages.

About VLC: http://taper.alienbase.nl/mirrors/pe...ackbuilds/vlc/ has a package, pre-built, no external dependencies needed (except for libdvdcss i you want to play DVD's).

Eric

GazL 02-23-2013 09:47 AM

I'm not really sure what you mean by another location, but you can store them wherever you like.

I like to follow a layout similar to the slackware patches/ tree itself:
e.g.
Code:

slackbuilds/
slackbuilds/packages
slackbuilds/packages/dmenu-4.5.gazl1-x86_64-1_local.txz
slackbuilds/packages/dwm-6.0.gazl5-x86_64-1_local.txz
slackbuilds/source
slackbuilds/source/dwm
slackbuilds/source/dwm/dwm.SlackBuild
slackbuilds/source/dwm/slack-desc
slackbuilds/source/dwm/dwm-6.0.gazl5.tar.gz
slackbuilds/source/dmenu
slackbuilds/source/dmenu/slack-desc
slackbuilds/source/dmenu/dmenu.SlackBuild
slackbuilds/source/dmenu/dmenu-4.5.gazl1.tar.gz
...

Whether you put them on a usb thumb stick, external hardrive, samba share, or even just a directory on your local system such as /root (but don't forget to back them up if you do) is entirely up to you.

stringchopper 02-23-2013 10:06 AM

Quote:

Originally Posted by Alien Bob (Post 4898180)
If you ever want to upgrade to a newer version of Slackware, there is a possibility that you have to recompile some of the packages. In that case it is wise to keep the sources, SlackBuild scripts etc... but otherwise, it is OK to just keep the binary packages.
Eric

Thanks.

@GazL - I mean "another location" where the binaries are. Sorry for being so newbish - I just don't have enough fundamental knowledge (yet) to be able to define my questions properly or to understand what all is going on in the system.

I can read up on backing up and restoring - I think that will help me to know which binary directories and library directories to backup.

In any case, I will follow the advice to keep the scripts and sources.

GazL 02-23-2013 10:54 AM

Quote:

Originally Posted by stringchopper (Post 4898188)
@GazL - I mean "another location" where the binaries are. Sorry for being so newbish - I just don't have enough fundamental knowledge (yet) to be able to define my questions properly or to understand what all is going on in the system.
I

Ahh, I see what you're getting at now. There are a couple of approaches to backing up and recovering a system: One is to back it all up and restore it all if needed. The other is to backup only your data and any config files you've changed and re-install the OS before restoring your data on-top of it. Keeping your slackbuilds and packages around helps immensely if you choose to follow the second approach, but has less value if you follow the "back it all up" route as the things you've installed will already be included in your backup. As it happens, I actually do both! ;)

But as Eric has pointed out, keeping the slackbuilds around can make it pretty easy to upgrade stuff too. For example when a new version of Opera comes out, I download from Opera the new .rpm file, put it into my slackbuild source directory, and just re-run the opera.slackbuild and out pops a nice new slackware packaged version.


In the interest of full-disclosure, there is also another reason I keep the package files around, and it's to do with the fact that I use something other than slackpkg to help manage my system updates, but that's a discussion for another day and not really relevant here. :)

tronayne 02-24-2013 08:32 AM

Consider a couple of thing about back up; you have the Slackware release CD-ROM/DVD which means that it's not necessary to back up the entire system (you can simply install Slackware on a new platform or disk drive if you've had a catastrophic failure). What you do need to back up, though, are the official Slackware patches, anything you've added to your system and the entire content of the /etc directory (where you've configured things). You also really want to periodically back up the entire content of /home -- that's where all your stuff ought to be. Basically what you want to do is walk it forward, staring with the distribution disk and stop-by-step restore additions (and we're talking total failure here, not day-to-day).

If there is a failure, you install Slackware, install all the patches (using upgradepkg *.t?z), then copy certain files from your saved /etc (the passwd file, the shadow file, possibly some configuration files). Once that's done, you can simply restore /home.

Now what does "additions" mean? Any SlackBuilds.org packages (either the source or the source plus the package -- the .tgz file). LibreOffic or OpenOffice (or both)? Data bases? /var/lib/mysql or /var/lib/psql (or wherever you put them). Web page? /var/www. Anything you've built with src2pkg (excellent tool, that). Fonts you've added.

Doing what's known as a level 0 back up (everything) takes a lot of media and a lot of time; my home directory alone is just under 4G, the root directory is just under 10G and then there's all the other stuff -- lots of media to store all that and, well, it's just not too practical in many cases to do a level 0. You do, of course, have to discipline yourself to actually do back up periodically (even if it simply copying things to a spare disk drive or another system when you make changes or additions).

The thing I do (that may or may not make sense to everybody) is that all add-on software is kept in /usr/local/packages. Patches are kept in /usr/local/patches. Add-on fonts are in /usr/local/fonts (and are installed in /usr/local/share/fonts. That sort of thing. I copy the entire /usr/local tree to my other servers, with one copy on a DVD that I burn weekly. I do have more than one system (there are four, two 64-bit and two 32-bit) that are all configured identically, same disk partitioning, same software (even if it's not used; the two 32-bit boxes are data base servers, one MySQL the other PostgreSQL, but they've got full boat installations). The patch files, both 32-bit and 64-bit (in separate subdirectories of course), are on all severs. You should do what you're comfortable with, just be sure to CYA -- when a box blows up (and they do), what can you afford to lose might be a good guide. Copying stuff across your LAN goes really quickly, copying to media doesn't.

A side note about /use/local: I install add-on software in /usr/local (which can take some fiddling with the SlackBuild scripts). I just have a thing about not installing "local" software in the root system. Part of that is about back up, part of it is about "polluting" the distribution base (been burned, didn't like it, so I keep "church and state" separate). That's not for everybody, it's just my peculiarity and it works for me; there are, of course, things that aren't workable that way, one of which is optional software such as LibreOffice and OpenOffice which get installed by default in /opt. That's an exception to my rule, but that is what the /opt tree is for so OK. That's also true of Adobe Reader (on 32-bit systems only or with multilib), that goes in /opt by default. Everything else, non-system libraries, non-system executables, whatever, goes in /usr/local (where there are a standard set of directories like bin, doc, etc, include, info, lib, lib64, man, sbin, share, src and so on). This scheme fits in with the back up and restore model described above. And, oh, by the way, works just fine.

So, anyway, consider all the advice offered by experienced folk in this thread and see what makes sense to you in your installation and figure out what you're comfortable with and can handle and go for it.

Hope this helps some.

stringchopper 02-27-2013 06:58 AM

Quote:

Originally Posted by tronayne (Post 4898644)
Consider a couple of thing about back up; you have the Slackware release CD-ROM/DVD which means that it's not necessary to back up the entire system (you can simply install Slackware on a new platform or disk drive if you've had a catastrophic failure). What you do need to back up, though, are the official Slackware patches, anything you've added to your system and the entire content of the /etc directory (where you've configured things). You also really want to periodically back up the entire content of /home -- that's where all your stuff ought to be. Basically what you want to do is walk it forward, staring with the distribution disk and stop-by-step restore additions (and we're talking total failure here, not day-to-day).

If there is a failure, you install Slackware, install all the patches (using upgradepkg *.t?z), then copy certain files from your saved /etc (the passwd file, the shadow file, possibly some configuration files). Once that's done, you can simply restore /home.

Now what does "additions" mean? Any SlackBuilds.org packages (either the source or the source plus the package -- the .tgz file). LibreOffic or OpenOffice (or both)? Data bases? /var/lib/mysql or /var/lib/psql (or wherever you put them). Web page? /var/www. Anything you've built with src2pkg (excellent tool, that). Fonts you've added.

Doing what's known as a level 0 back up (everything) takes a lot of media and a lot of time; my home directory alone is just under 4G, the root directory is just under 10G and then there's all the other stuff -- lots of media to store all that and, well, it's just not too practical in many cases to do a level 0. You do, of course, have to discipline yourself to actually do back up periodically (even if it simply copying things to a spare disk drive or another system when you make changes or additions).

The thing I do (that may or may not make sense to everybody) is that all add-on software is kept in /usr/local/packages. Patches are kept in /usr/local/patches. Add-on fonts are in /usr/local/fonts (and are installed in /usr/local/share/fonts. That sort of thing. I copy the entire /usr/local tree to my other servers, with one copy on a DVD that I burn weekly. I do have more than one system (there are four, two 64-bit and two 32-bit) that are all configured identically, same disk partitioning, same software (even if it's not used; the two 32-bit boxes are data base servers, one MySQL the other PostgreSQL, but they've got full boat installations). The patch files, both 32-bit and 64-bit (in separate subdirectories of course), are on all severs. You should do what you're comfortable with, just be sure to CYA -- when a box blows up (and they do), what can you afford to lose might be a good guide. Copying stuff across your LAN goes really quickly, copying to media doesn't.

A side note about /use/local: I install add-on software in /usr/local (which can take some fiddling with the SlackBuild scripts). I just have a thing about not installing "local" software in the root system. Part of that is about back up, part of it is about "polluting" the distribution base (been burned, didn't like it, so I keep "church and state" separate). That's not for everybody, it's just my peculiarity and it works for me; there are, of course, things that aren't workable that way, one of which is optional software such as LibreOffice and OpenOffice which get installed by default in /opt. That's an exception to my rule, but that is what the /opt tree is for so OK. That's also true of Adobe Reader (on 32-bit systems only or with multilib), that goes in /opt by default. Everything else, non-system libraries, non-system executables, whatever, goes in /usr/local (where there are a standard set of directories like bin, doc, etc, include, info, lib, lib64, man, sbin, share, src and so on). This scheme fits in with the back up and restore model described above. And, oh, by the way, works just fine.

So, anyway, consider all the advice offered by experienced folk in this thread and see what makes sense to you in your installation and figure out what you're comfortable with and can handle and go for it.

Hope this helps some.

Good tip about /usr/local/. Maybe if you have time, you could explain more about more about what you do to the slackbuild scripts to customize the directory (?)...

tallship 02-27-2013 10:30 AM

Quote:

Originally Posted by tronayne (Post 4898644)
The thing I do (that may or may not make sense to everybody) is that all add-on software is kept in /usr/local/packages. Patches are kept in /usr/local/patches. Add-on fonts are in /usr/local/fonts (and are installed in /usr/local/share/fonts. That sort of thing. I copy the entire /usr/local tree to my other servers,

Hope this helps some.


Quote:

Originally Posted by stringchopper (Post 4900752)
Good tip about /usr/local/. Maybe if you have time, you could explain more about more about what you do to the slackbuild scripts to customize the directory (?)...

I do something quite similar to what troynane describes above. I find it to be the most logical approach (especially with consideration to how one historically uses UNIX in an enterprise environment) for both home and business installations alike.

/user/local/packages (package repo)

/usr/local/slackbuilds (SBo repo w/sources in the untarred dirs)

etc....

With the latest NFS, you can even securely mount a remote /usr/local/packages under each of your local machines' /usr/local over the open Internet. But that's a different topic altogether :)

There's a couple of ways you can do what you're asking, which is what I do. I'll briefly cover the first method, which you need to understand anyway, before implementing the second way - which for most is an even better way to acheive this same thing.

I should mention that the 'second way' doesn't always work in all cases. Why? Because there are login shells and non-login shells, .bashrc and other files that initalize your shell environment - so when you use things like tmux or screen you must take the shells that are spawned into account in your particular corollary to the .profile construct.

I hope that makes sense. I'm a little tired and need a nap right now lol.

Anyway, to directly address your question here's what you can do:

  • Method #1 (Intrusive) - Manually edit *.SlackBuild or sbo.conf files


Change the line in <package_name>.SlackBuild from:

Code:

OUTPUT=${OUTPUT:-/tmp}
to:

Code:

OUTPUT=${OUTPUT:-/usr/local/packages}
Now, the next logical layer to include in your package management is the use of sbopkg, which downloads the SlackBuild, untars it, downloads the source, runs the *.SlackBuild, and installs the resulting package.

To modify sbopkg to accommodate your question...

edit /etc/sbopkg/sbopkg.conf and change the following:

Code:

export OUTPUT=${OUTPUT:-/tmp}
to

Code:

export OUTPUT=${OUTPUT:-/usr/local/packages}
That was just the first way to do this, and as you can see (especially in the case of modifying each and every SlackBuild script) becomes a little mundane after a while, regardless of how trivial you may find the adjustment ;)

So next Is the second way, exporting some of those variables into your shell's environment. Before any of this, however, you should have those directories, of course:

Code:

# mkdir -p /usr/local/packages
# mkdir -p /user/local/slackbuilds

etc...

  • Method #2 (Non-intrusive) - Export environment variables


This second method, is mentioned on the SBo mailing list, thanks for Chris Abela and David Somero for the hints ;)

Quote:

No reason to edit the Slackbuild at all add something like this to you profile:

export OUTPUT="/usr/local/packages"
export PKGTYPE="txz"

or

OUTPUT="/usr/local/packages" PKGTYPE="txz" <package_name>.SlackBuild

--dsomero
And the methodology that Chris uses:

Quote:

My choice was to write a small /etc/profile.d/local.sh (with executable permissions of course). Then I use sbopkg most of the time.

#!/bin/sh
# SBo parameters
export PKGTYPE=txz
export OUTPUT=/home/chris/packages
export QUEUEDIR=/home/chris/queues
export SBo='/var/lib/sbopkg/SBo/14.0/'

That's all I needed. The /usr/local/ choice is enticing as well, but I am not sure that was the original intention of the directory.
Once again, using this second method (exporting to your shell environment), things can act other than what you expect when using multiplexors like screen and tmux - so configure those tools accordingly and check your environment from within them with:

Code:

# set
To make sure that your environment is correct for your purposes when using screen or tmux ;)

The advantages of using /usr/local/.... are numerous, and when you have a bunch of servers in a farm located in racks it becomes even more advantageous to simply mount a single /usr/local mountpoint on all of the machines in that farm - one place to put your fonts, packages, patches, SBo's, and other ditties you need to distribute between all machines.

Not only that, but you can run your SlackBuild scripts or sbopkg on any machine and the packages are neatly placed in the commonly shared /usr/local/packages dir. So you can run through your package creation process on any one of the machines and as soon as it is done simply cd into /usr/local/packages on each of the systems and do an installpkg, upgradepkg, removepkg, or pkgtool.

One last thing. don't forget to occasionally clean your /tmp - things start taking up space as time goes by, and things like LibreOffice and Firefox... Well, they're kinda large lol.

Here are the links to those two posts in the thread:

http://slackbuilds.org/slackbuilds/1...ake.SlackBuild (Chris's post)

http://lists.slackbuilds.org/piperma...ry/010098.html (David's post)

OH Wait! There's one more thing that really deserves mentioning. Take a look at the last line in Chris's /etc/profile.d/local.sh:

Code:

export SBo='/var/lib/sbopkg/SBo/14.0/'
Do you see how he breaks out his SBo's by Slackware version too? You can do this with the $OUTPUT variable for your packages, and maintain several versions at once, moving forward with some machines while the older machines still have access to the packages intended for those earlier versions of Slackware.

I hope that helps :)

Kindest regards,

.

psionl0 02-27-2013 11:26 AM

Quote:

Originally Posted by stringchopper (Post 4900752)
Good tip about /usr/local/. Maybe if you have time, you could explain more about more about what you do to the slackbuild scripts to customize the directory (?)...

It should be pointed out that the tip about /usr/local is useful mainly if you have a separate HD partition mounted at that point. That way, you can have a stock standard Slackware installation on one partition and all your additional packages installed in another partition. Of course, if you really want to dedicate a partition only to the original Slackware installation, you should also have another HD partition mounted at /opt.

Changing a SlackBuild script to install the package files to /usr/local is usually straightforward enough. There is generally a section in the script that says,
./configure \
--prefix=/usr \
--libdir=/usr/lib${LIBDIRSUFFIX} \
--sysconfdir=/etc \
--localstatedir=/var \
--mandir=/usr/man \
--docdir=/usr/doc/$PRGNAM-$VERSION \
--build=$ARCH-slackware-linux

and you can simply change the references to /usr to /usr/local. If you are using src2pkg to create a package, you can use the option "-p=/usr/local".

It should be noted that not all sources have a well behaved configure or Makefile and the script often has to do special tricks to make the files go where they should (eg use 'sed' on the Makefile). So you might have to make yourself a bit of an expert on SlackBuild scripts. It should also be noted that it is not possible to keep everything out of the original Slackware partition - especially files that go into the /var directory. At the very least, /var/log/packages/ gets updated when you install any package so if you do a fresh installation of Slackware, you are also going to have to install the packages separately anyway.

For this reason, I am usually content to stick to the Slackware philosophy of using /usr for my package installation destinations. As long as you only install packages (and not individual files) there, there is no real problem. 'removepkg' will remove the files if you need to without causing any harm elsewhere. This leaves /usr/local as my personal "playground" where I can install special scripts/executables without messing anything else up. As of late, I try to make a package out of everything that I intend to install system wide (even if it's just one or two files) so /usr/local is a bit of a lonely place on my system.

tallship 02-27-2013 11:46 AM

I too, tend to leave the locations where packages want to install their files as is, with rare exceptions.

Smarter people than I have wrestled with those sources for the benefit of the community and therefore I merely keep my sources, SlackBuild scripts, as well as my unexploded packages archived under /usr/local/...

As psionl0 points out, There are good reasons for keeping the location where most of your binaries are installed as /usr ;)

Kindest regards,

.

psionl0 02-27-2013 01:00 PM

Quote:

Originally Posted by tallship (Post 4900974)
I merely keep my sources, SlackBuild scripts, as well as my unexploded packages archived under /usr/local/...

I use /home/slackbuilds/... for that purpose since /home is a separate partition.

stringchopper 02-27-2013 04:34 PM

Good Stuff! Thanks for the tips tallship & psionl0


All times are GMT -5. The time now is 09:45 AM.