Dropline doesn't have a single convenient tarball full of all the sources because they're mainly unneeded. The build system knows where the sources are and will download anything it needs on-the-fly. Any patches that were applied at build time and basically everything needed to replicate the packages gets distributed in the
binary package (because this is typically only about <20k worth of stuff, if that). Setting up for replication/testing is fairly simple as a result.
You can get the last tarball of the
Dropline Build System (
sig)
and untar it into
/usr/src (this place for a reason).
If you've already installed Dropline you might have slightly newer build definitions than are in that tarball (so you don't want to overwrite them). The tarball will have uncompressed as /usr/src/dropline-build-system-1.97.15.4 and the files that came in with Dropline packages will be in /usr/src/dropline-build-system. Transfer these newer files into the archive and put things in their proper places with these three commands:
Code:
cp -R /usr/src/dropline-build-system/* /usr/src/dropline-build-system-1.97.15.4
rm -rf /usr/src/dropline-build-system/
mv /usr/src/dropline-build-system-1.97.15.4 /usr/src/dropline-build-system
If you have
not installed Dropline, just rename dropline-build-system-1.97.15.4 to dropline-build-system.
You will want to look at the file named "config" that is now sitting in /usr/src/dropline-build-system (which is referred to as DLG_ROOT) and maybe uncomment/change a few things, and I'll list them (the Wiki is broken at the moment or I'd have fixed this long ago). (I would suggest
not going overboard here.)
DLG_SOURCEREPOS - This variable does double-duty. It both sets where the engine
looks for already-downloaded source tarballs, as well as where it
stores what it downloads. Set the last argument in it to somewhere with a lot of free space. Whenever you tell the engine to build something, if it can't find a local copy of the source, it'll download it and store it there. You probably don't have a /space/tarballs directory so set this.
DLG_PKGER - This is set to "dl" usually, but stick your initials or something in there so you'll be able to tell what you built apart from things other people have built.
DLG_ARCH and
DLG_CPU - If you absolutely, positively want packages that are built with PV's traditional 486-friendly settings, what you need to do here will be fairly obvious. Otherwise you can leave them alone, as the default results in aiming for -O2 -march=i686 (some software has other ideas, and each definition is supposed to do it's best to not interfere while staying as close to this as it can).
DLG_PACKAGEROOT - (almost at the bottom) This directory controls where the completed, installable packages are stored. There should probably be a reasonable amount of space wherever this is.
DLG_SCRATCHROOT - This defaults to /tmp/DLG and is where the engine does all of it's "work", keeps copies of log files, etc. If you for whatever reason have a very tiny or nearly full /tmp, you will definitely want to change this. Some (but very few) packages may potentially use as much as 200-300Mb of disk space during their builds and you don't want to run out of disk while something is compiling.
Beyond that, the rest is pretty simple/straightforward. If you look in DLG_ROOT/SCRIPTS you will see a bunch of subdirs that each contain three files. "build" is the core of the package definition that says what is to happen and in what order. "ChangeLog" is somewhat obvious.
Always update this when you change anything or build a package--it makes life easier. "desc" is just the file that will become slack-desc in the final package.
To actually build a package is pretty simple. We'll use Zenity as an example. You'd make whatever changes you wanted to DLG_ROOT/SCRIPTS/zenity/build, then update DLG_ROOT/SCRIPTS/ChangeLog, and then from DLG_ROOT (as in, cd /usr/src/dropline-build-system) you run `./build zenity` and let it do it's thing.
Beyond that there is a README in DLG_ROOT that explains a few things in more detail, and if you want API documentation on what functions are available for use in the build scripts, do the following:
Code:
grep "^##" SCRIPTS/dropline-functions.sh | less
The documentation could probably stand to be reordered and cleaned up a bit, but with the 200+ example scripts, it's kind of hard to get really confused.
Dropline is not for everyone
Sources and building Dropline
