Special files used by or generated by src2pkg This file briefly explains the purpose and use of special 'extra' files which are used by src2pkg or that src2pkg can create during package building. Where $NAME is used, this means the bare case-sensitive name of the software being packaged. xprog != XProg First Column Second Column Name of file Search locations (PATCHES_DIR defaults to CWD unless you set it to be separate) ******************************************** ### *.patch and *.diff files # patch and diff files are handled automatically. They can be plain files or # compressed gzip files, or even debian *.dpatch files. # patches are applied automatically in 'natural' sort order. If you need to # change the order of applying them, the easiest way is to rename them # with numbers as the first part of the name 00-some.diff, 01-another.patch *.diff CWD, PATCHES_DIR/NAME-patches, PATCHES_DIR/NAME, CWD/patches CWD/Resources *.diff.gz "" *.patch "" *.patch.gz "" *.dpatch "" # some patch files(debian) have the '.gz' ending, but are not really compressed # files. These are correctly handled as plain text files. not gzipped files. ### ### # Patches will be detected automatically by src2pkg simply by placing them in # the CWD (Current Working Directory) where src2pkg is run from, or in a subdir # of the CWD. The subdir can be named Resources, patches or $NAME-patches (where # NAME is the name of the package, of course). Once you have the build working # correctly, you can create a .tar.gz or .tar.bz2 archive of the Resources, # patches or $NAME-patches subdirectory to save space. src2pkg will automatically # unzip the archive before applying the patches and will automatically remove # the directory when finished if the -W or --cleanup option is used. # Patches can also be placed in a separate PATCHES_DIR or PATCHES_DIR/NAME-patches # PATCHES_DIR defaults to CWD ******************************************** ### these are handled by 11-create_docs ## document items # these get automatically installed to DOC_DIR -usually PKG_DIR/usr/doc/$NAME-$VERSION $NAME.html CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources $NAME.xpm SRC_DIR, CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources $NAME.png SRC_DIR, CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources ## pkgconfig and *desktop files # these go to LIB_DIR/pkgconfig -usually: /usr/lib(64)/pkgconfig *.pc SRC_DIR, CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources # these go in DATA_DIR/applications -usually: /usr/share/applications # a routine gets added to doinst.sh ro update the desktop database *.desktop SRC_DIR, CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources ## configuration files under /etc, /etc/rc.d and /etc/X11/xinit # these get put in PKG_DIR/etc/X11/xinit xinitrc.*.new CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources xinitrc.* CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources # init files for 'services' go to PKG_DIR/etc/rc.d (INIT_DIR ???) # these get a routine written in doinst.sh which creates and entry # in /etc/rc.d/rc.local for the new service, when the package is installed rc.* CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources rc.*.new CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources $NAME.conf CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources *.new CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources # Any *.new files also get a routine written for them in doist.sh # which upgrades the file using the familiar config() function ### ******************************************** ### these are handled in 13-make_description # these can actually have another name (like pkg-desc) by setting PKG_DESC # patterns: $PKG_DESC-$NAME $PKG_DESC $NAME-$PKG_DESC $NAME.$PKG_DESC $NAME.txt # paths: PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources slack-desc new.slack.desc when using -A, generated slack-desc files gets copied to CWD/new.slack.desc If you supply one it will be used, but only after verifying that there are 9-13 $NAME: lines. Otherwise, one is always generated. Using -A only makes it get copied to CWD/.new.slack-desc # these must be manually created if you want them # they can also have another name like pkg-suggests or pkg-conflicts slack-suggests CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources slack-conflicts CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources ### ******************************************** ### these 4 are all handled in 14-make_doinst and go in the /install directory ## doinst.sh -these get used as-is if they are present: # doinst.sh-$NAME doinst.sh-$NAME.gz doinst.sh doinst.sh.gz $NAME-doinst.sh # $NAME-doinst.sh.gz $NAME.doinst.sh $NAME.doinst.sh.gz doinst.sh CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources doinst.sh.gz CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources ## slack-required and slack-supplies # used as-is if already present or generated if you use -E # generating these causes the creation of several temporary files, all in CWD, # but they are removed before package building proceeds. # if using -A, these get copied to CWD if not already there slack-required CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources slack-supplies CWD, PATCHES_DIR/NAME-patches, CWD/patches CWD/Resources # by default a doinst.sh gets created if needed and one is not already in the # PKG_DIR or found in the search paths above. In addition to the # normal routines which remove any links from the package and creates # link creation lines in a PKG_DIR/doinst.sh script ## doinst.prepend & doinst.append # these files let mix hard-code with auto-generated link routines # from above. If you have har-coded lines you want inserted in the doinst.sh # script before the link-creation lines, put the code in doinst.prepend # if you want coded after the link-creation lines, use doinst.append doinst.prepend CWD CWD/Resources PATCHES_DIR/NAME-patches CWD/patches doinst.append CWD CWD/Resources PATCHES_DIR/NAME-patches CWD/patches # when using -A, new doinst.sh gets copied from the package to CWD/new.doinst.sh new.doinst.sh ### ******************************************** ### md5sums optionally generated by 15-make_package $NAME-$VERSION-$ARCH-$BUILD$SIG.md5 CWD ### $NAME.src2pkg and $NAME.src2pkg.auto scripts # When using -N or -A a src2pkg script is generated in CWD named $NAME.src2pkg.auto # Always change the name to simply $NAME.src2pkg to keep it from being overwritten # Running repeatedly using -N will clobber any *.src2pkg.auto already present # Running again using -A will *not* clobber any already-present *.src2pkg.auto # scripts named without '.auto' have precedence when using -X to search and run $NAME.src2pkg.auto CWD $NAME.src2pkg CWD # it's handy to always have a script for the build, even if no special code or # extra instructions are needed for the build. In these cases, I leave the build # script named $NAME.src2pkg.auto to disinguish them from the ones that *do* need # extra stuff. If you are going to edit your build script, be sure to change the # the name first, to just plain $NAME.src2pkg. That way it never gets clobbered and # the name provides a visusal clue so just one look at the file and you know whether # it contains something special. ### ====== Special Files and src2pkg script FAQ ===== 1. What's the difference bewteen new.* and *.new Filenames which start with 'new' are files generated by src2pkg. They will get over-written each time you re-run using -A or -N. Removing the 'new.' part from the name leaves them with their 'official' name. Changing to the 'official' name means the files get used as-is and theat they will not be over-written or removed. Giving the file its 'real' name tells src2pkg: "I want you to use this." Filenames that *end* with '.new' are a special kind of configuration file. A special routine in the doinst.sh script dor the package, makes these files get special treatment when the package is installed and the doinst.sh script is run. '*.new' files have the 'official' name when the '.new' part is removed. But, the doinst.sh handles these files with a small routine which compares the new '*.new' file with any file with the official name which is already installed on the system. The result is that, if you have a conf file (say /etc/prog.conf, for example) which you have edited, then if your package contains an etc/prog.conf.new file, your original prog.conf will not be overwritten by the prog.conf.new file. Otherwise, prog.conf.new will get renamed to prog.conf, replacing the old one, when the package is installed -in most cases. You have to create *.new files yourself. Naming them *.new just tells src2pkg to be sure and write the special routine to handle them into the doinst.sh script for the package. 2. Why are some of the lines like "STD_FLAGS=??" in the $NAME.src2pkg file commented out? Some lines are shown in the script mostly as information on the default options which were used to create the package, and to make it easy for you to edit them if they need to be different. But they are commented out if they are system-dependent options and not package-specific. STD_FLAGS is a good example. On a regular Intel PC, the STD_FLAGS would probably show as: STD_FLAGS="-O2 -march=i486 -mtune=i686". but on an AMD64 they might be STD_FLAGS="-O2 -fPIC" or on a PPC machine just STD_FLAGS="-O2". These options aren't package-dependent, they depend on which system is being used. And the default STD_FLAGS are usually calculated by src2pkg according to the system or they are set to whaver you like/need in the src2pkg.conf file, where they will always be used unless overridden by the $NAME.src2pkg script. If the line for STD_FLAGS were left uncommented, then the script would most likely have to be edited by hand in order to build the same software on a different system. Other options which have a direct bearing on the success of the build on any platform are left uncommented so they *do* get used -like EXTRA_CONFIGS, if in use. If you auto-generate a $NAME.src2pkg.auto script using -A or -N, then src2pkg will sort out what should be commented and what should not. You can always uncomment or edit any lines that need it. 3. What are the minimum lines needed, then for a NAME.src2pkg script? Just three (3) lines! Like this: SOURCE_NAME=some-prog.tar.bz2 . /usr/libexec/src2pkg/FUNCTIONS do_all_processes Of course this only works if no special options or instructions are needed to build the package. This also means you could build the package without any script at all, just by running 'src2pkg prog.tar.bz2'. You could even have it download the sources for you by running 'src2pkg URL' where URL is the internet address of the sources. 4. What is that do_all_processes? I don't see that in my scripts. do_all_processes is a short-cut function which simply runs all the normal steps for building a package -in their normal order. Whe src2pkg writes a script for you, it lists all the steps individually to make it easier for you to comment out a step so that it gets skipped, or for you to add extra code bewteen the normal steps.