########################################################################## # Document: armedslack-current/source/UNDERSTANDING_SOURCE_TREE.txt # Purpose : Describe the ARMedslack source tree # Author..: Stuart Winter # Version : 1.00 # Date....: 13-Jun-2004 ########################################################################## ## NOTE: THIS IS OLD -- NEEDS UPDATING ---- [1] The stuff about scratchbox is largely nonsense - I build *everything* bar glibc and gcc3.4 natively now [2] I very rarely use *any* Debian patches [3] If you think half the source build scripts are missing, it's because I haven't done them yet! :-) Even if there is a binary package but the source build tree for it looks in a shambles then that indicates that the binary package needs to be rebuilt. It *will* be rebuilt and a new build script written, but please don't bug me about them unless the packages don't work. This document will be updated in due course. 1. Building a package ------------------ Instead of using foo.build or foo.SlackBuild, the way to build packages is # cd sourcedir # arm/build You'll notice that some of the source directories do not have an arm/build file, or even an arm directory, but just a trackbuild or a foo.SlackBuild script. These are old and I haven't got around to updating them or rebuilding the package yet, but in time they will do. That should build you a package and dump it in the directory that is defined by $PKGSTORE You need to install the slackdevkit-??-arm-?.tgz package and modify /etc/slackdev/buildkit.sh to suit your needs. You can find this package in the armedslack-xx/extra directory. It's also worth noting that I mainly build ARMedslack inside 'Scratchbox' ( see http://www.scratchbox.org ) rather than natively. As such, some build scripts have stuff that is specific to scratchbox in them, so you won't be able to build natively without modification. Unless there is a file named 'NATIVE_BUILD' inside sourcedir/port then you can assume that it is built inside Scratchbox and has never been built natively. The StrongARM RiscPC is simply too slow to build natively. Because I *do* use scratchbox, I also need to make use of Debian's 'fakeroot' (pretends that you're root) program in order to set uid & gids other than that of which I'm currently logged in as on the x86 Slackware system. You can see me using fakeroot in the port/pkger, or sometimes inside the foo.SlackBuild script (if necessary). Where I start fakeroot depends on whether the package requires any ownerships other than just root.root or root.bin. For example, the uucp package requires that some ownerships are 'uucp.uucp', and as such I need to start fakeroot before 'make install'. I also include (where relevant) a port/*.diff file so that I can (hopefully) easily patch the new SlackBuild/.build script that comes from Slackware-current. As you look through the source tree, it should become apparent. 2. Modifications to Slackware build scripts ---------------------------------------- Because Slackware is very x86-centric, I need to modify the build scripts. Usually my modifications are very minimal so that it's easier for me to keep up to date with Slackware-current. You may notice that I often have || failconfig, || failmake and so on inside some build scripts (although with the more recent build scripts, I no longer do this as it's not required). For the SlackBuild scripts I typically remove the VERSION= BUILD= ARCH= lines, because these are set by arm/build I then export the PKG= variable: export PKG=/tmp/package-foo This is so that port/pkger can cd into $PKG to perform the operations before finally running makepkg. For .build scripts, I usually just modify the ARCH variable and remove the VERSION variable, or make it take the version from the trackbuild script (so it has VERSION=$1 ). In order to track the changes on the file system (in order to determine what makes it into the package), I use a modified version of altertrack (part of the slacktrack package in Slackware-9.1+). The only modifications are to enable it to work with Scratchbox. This version of altertrack is not available, but you can replicate it by reading the document detailing the steps about how to setup Scratchbox for building ARMedslack from source (it simply uses perl to replace a few paths). 3. Use of Debian patches and updated or downgraded software -------------------------------------------------------- Sometimes stuff doesn't build with gcc3.4 or doesn't build for ARM. Usually I look at it and if it doesn't appear obvious as to why it's not building, I go to http://packages.debian.org, select 'any' as the distribution and search for the package. I then find the newest version and download the .diff and if necessary grab a new version of the software too. Sometimes Debian don't have a diff for the most up to date version, or aren't using the most up to date version on the ARM architecture. Therefore, I downgrade to the version they're using. If I'm using Debian patches, you can always find a download.source file which when run, will check for the existence of patches/source and download accordingly. I'm not particularly keen on using Debian patches, as they often change things to fit in with Debian's policy which don't agree with Slackware's and cause things to break in odd ways. I will look at these on a case by case basis in the near future, and hope to narrow down what exactly is being patched and why, then only grab out the *required* changes. However, this takes time, but rest assured that I *will* do it. However, in some occasions I've totally replaced the stuff in Slackware with other packages/compatible packages from Debian (an example is sysklogd) because I couldn't get the version included with Slackware to compile at all. If you spot any problems with these then of course, please let stuart@armedslack.org know about it, and if you can fix the original Slackware version then please do so! Upgrading a package ------------------- Knowing when ------------ # cd packagesourcedir # ./differ This will report any changes between the stored originals build script(s) on which ARMedslack's are based and those in your slackware-current tree. If you only see that nothing but the BUILD number has changed, this could be for two reasons: [1] The package has been recompiled (usually to be linked against a new library or to be linked against a newer release of an existing library) [2] If the package makes extensive use of 'framework' archives (_foo.tar.gz) then it's possible that something has changed within this archive. An example of this is the 'sysvinit' package from the a/ series. Upgrading ARMedslack's packages ------------------------------- Once you have determined that a package should be rebuilt: Find the relevant changes and merge them (if necessary) into ARMedslack's scripts: # ./differ Update your stored copy of the original script: (they may be named something other than SlackBuild, or there may be more than one build script): # cp -f ~/slackware-current/source/series/blah/blah.SlackBuild blah.SlackBuild.orig Rebuild the package. If it's a 'clean' SlackBuild script then: # arm/build If it's a script that will install on to the file system: # ./trackbuild.blah