Creating DEBs from scratch

If you’ve ever made a deb, you’ve likely noticed the confusing file of helper apps and scripts. I initially fell back on just using dpkg-deb. For a current project though, I needed to make the deb completely from scratch.

I’m attempting to make a deb for Oracle Database. The touted “Oracle Universal Installer” is a huge pile of shit, that is, a X based java program. Even when I run it in silent mode with a scripted response file, it still tends to spawn itself out as a new parent so I can’t keep my scripts around it. My solution has become to perform a scripted install on a box, then package the completed install (the whole whopping 1.5GB of it) into a deb. I don’t want to move the 1.5GB binary tree into my deb build folder, so I decided to create the deb by hand. This is simple up to a point.

Of all the discussion out there about the deb format, the best reference is simply the deb man page. I couldn’t find much in the Debian Policy Manual or New Maintainers Guide.

A deb is an ‘ar’ archive containing debian-binary, control.tar.gz and data.tar.gz.

These files should be in this order. debian-binary should contain a single line with the text “2.0” to specify the new deb version. control.tar.gz should be a tar file, gzipped, containing the control file and other scripts as specified in the the aforementioned guides. data.tar.gz should contain the files you want the package to install.

So:

echo “2.0” > debian-version
ar r newpackage.deb debian-version control.tar.gz data.tar.gz

Control.tar.gz should be created from within your standard DEBIAN directory, ie:

cd DEBIAN
tar -cvzf ../control.tar.gz .

Data.tar.gz should be created at the root of a file system in the same manner, obviously only including the paths you want to be included.

I’m still unable to please all the deb packages with this format. There was discussion years back amongst debian developers to stick to the “bsd” format for ar and not use the “gnu” format which supported spaces in filenames by adding a slash to the end of the filename as a terminator in the format. Best I can tell, OpenBSD and FreeBSD have since switched to using gnu binutils as well, so I can’t even find source for a reasonable modern version of non-gnu ar to compile.

Apt has it’s own ar code in the source that does things it’s way.

All of this was done to make debian packaging portable. Granted, the idea was more that you could access debian packages anywhere, rather than create them. Other than using sed or such to go in and modify the deb afterwards, I’m out of ideas.

Update: My Sed-foo is poor, but I tried to get sed to match the old bsd style for me with: sed -i ‘s/^\([A-Za-z.-]*\)\//\1 /’ file.deb, searching for text (filename with a slash) at the beginning of a line and replacing the slash with a space. This worked as far as apt-extracttemplates & ar was concerned but as was to be expected, somewhere within the data.tar.gz was corruption as a result. I’m sure a better regex would work.

Instead of spending more time on this, I went to the dpkg world. After the oracle software is installed, I tar the folders I want and pipe that back into tar in the build directory (ie cd / ; tar -c /apps/stuff /opt/stuff /etc/configstuff | tar -xC /home/build/build ; cd /home/build ; dpkg-deb -b build . ). Looks like it works okay. The real tests begin soon as the developers start using the package.

2 thoughts on “Creating DEBs from scratch

  1. Exospaca

    OpenBSD will never, ever, ever use GNU’s binutils, they never will. That’s a flat rule, FreeBSD doesn’t have the hardline approach and may very will use GPL code, but OpenBSD avoids it. OpenBSD’s developers went through the trouble of rewriting stuff like gzip, tar, diff, grep and many other programmes just to avoid the filth that is GNU. Pretty close to the only thing that the GNU make that OpenBSD uses is the GCC.

  2. btm

    I don’t have an obsd box here at the office, so I can’t easily tell if this obsd ar or this gnu ar is the official ar on openbsd. Perhaps the GNU binutils are just for the avr-binutils package or such. I’ll concede that it seems likely that openbsd would have it’s own ar, but I do point out that GNU binutils is probably in obsd cvs for a reason, and it’s certainly not to take the code; license issues and all.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.