a generic SlackBuild
Sometimes, I want to build a package from source. I like to make a Slackware package, so that it is easy to upgrade/remove the package in the future. checkinstall works for this most of the time, but not always. I have found it easier to create a SlackBuild for the package.
Since most software compiles fairly similar, I decided to create a SlackBuild template. I have tried to keep it as simliar to the SlackBuild scripts that the official packages use as possible. Please feel free to use this if it is useful to you. Any recommended changes/critiques are welcome. Code:
#!/bin/sh |
Shilo - thanks for this. I am sure that at least one of our members will be able to use it. Keep the ideas coming!
|
Good work shilo, I will try to build my own package shortly!
|
Hi Shilo
Nice one, this. Some positive feedback: Quote:
Code:
TMP=/home/alien/temp ./template.SlackBuild So the commented-out lines really should be uncommented. Quote:
Quote:
Cheers, Eric |
I built something similar, but it bit more extensive a while ago. It can be found at:
http://danieldk.org/buildpkg/ Some example buildfiles can be found at: http://builds.slackbasics.org/newsource/ buildpkg is practically the generic SlackBuild script plus some checksum validation stuff. BTW. it is not a serious attempt to build a 'generic package builder', just some script that I use to build own personal packages. |
Quote:
Code:
gzip -9 $PKG/usr/man/man?/*.? |
Quote:
Eric |
Quote:
maybe you could post a find command that would search through all the possible locations?? |
Code:
find $PKG/usr/man -name "*.?" -type f 2> /dev/null | xargs gzip -9 2> /dev/null |
Quote:
so i take it that the internationalized man pages are stored in the /usr/man directory and not in a directory such as the /usr/jp/man/ example above, right?? cool... |
Quote:
|
that's what i suspected... thanks for clearing that up, and thanks for the nice tweak you did to the find... :)
|
Excellent thread, all. Thanks for contributing
|
I've written a package build system which can use a template as simple as this:
#!/bin/sh BUILD="1" NAME="PkgName" VERSION="0.0.1" SRC_SUFFIX=".tar.bz2" source /usr/share/Amigo/PkgBuild/FUNCTIONS do_all_processes A more flexible template looks like this: #!/bin/sh ## Advanced.PkgBuild script for: PkgName ## ## Amigo PkgBuild-0.4 - Gilbert Ashley <amigo@ibiblio.org> ## ##### ------------Standard Package Variables------------------- # Most source code only needs these 4 variables set. # Set SRC_SUFFIX to ".tar.gz" ".tgz" ".tar.bz2" or ".tbz" BUILD="1" NAME="PkgName" VERSION="0.0.1" SRC_SUFFIX=".tar.bz2" #####--------Common Overrides and Options---------------------- # PRE_FIX="" # EXTRA_CONFIGS="" # DOCLIST="" # GROUP_NAME="" #######----------------Processing------------------------------ # Get functions and read in configuration files source /usr/share/Amigo/PkgBuild/FUNCTIONS ; # This template calls each process individually so you can add # extra instructions between processes, or even leave out steps. pre_process ; find_source ; make_dirs ; unpack_source ; fix_source_perms ; configure_source ; compile_source ; fake_install ; fix_pkg_perms ; strip_bins ; create_docs ; compress_man_pages ; make_description ; make_doinst ; make_package ; post_process ; exit 0 All the code for these functions are in the FUNCTIONS file. A couple of config files let you set up global prefs as to where to unpack, build and leave the created packages. The first example works for anything that will compile using autoconf and make: ./configure make make install The second example can be made to work for anything -multi-packages from one source, no configure, imake compiles, noarch packages, etc. The point is that the build script only has information about what is unique to compiling and building only that package. All other information is either part of the functions, or is a variable which can be always be easily overridden. It supports source/package grouping and regrouping, never actually installs the package unless you tell it to, works for suid programs. It also has a lot of extar features for generating dependency information and package reports, or for creating 'non-standard' packages with extra compression, culling of language files and other features. It's not perfect, but I turned it loose the other day on 83 source packages. A few hours later I had 83 binary packages, with temp directories all cleaned up. The really nice thing is that someone who can't code BASH at all, can write a build script for probably 80% of the stuff they want compile. The long form gives me an excellent way to *easily* see the details of anything that needs custonization. |
I have a similar script that I use when packaging programs. When I use it to package mplayer, gzipping the man pages will break a symlink. It looks like this script will have the same problem.
If I remember correctly... mencoder.1 -> mplayer.1 After gzipping mplayer.1, the mencoder.1 symlink is broken (it should point to mplayer.1.gz instead). Does anyone have a good solution for detecting and fixing this type of problem, rather than explicitly removing and recreating that specific symlink? |
All times are GMT -5. The time now is 05:43 PM. |