Version 6 (modified by jdreed, 12 years ago) (diff) |
---|
hello package - useful for understanding low-layer
- onyl 3 files needed: changelog, control, rules
- rules is executable
-- rules we look at: build, binary (binary-arch), clean build process: build stage (create programs), binary stage (make the binary package) The last step is dpkg --build, which creates the .deb -we should cover basic use of Makefiles (make, make install) and configure/autoconf -- sample package -- talk about DESTDIR and why important -example, run "debian/rules build"
"debuild:
- builds source package, then binary package, etc
- runs clean target
- sanitizes your environment (Variables, etc)
- can sign packages for you
binary target must be run as root (by extension, clean must be run as root) therefore, fakeroot. Ensures files in packages are owned by 0/0. ldpreload, between you and system
debian/tmp directory subtree
- docdir: debian changelog (->changelog.Debian), regular ChangeLog? (-> changelog) NEWS, etc
debian policy: gzipped manpages, permissions, owners, etc
arch-dependent vs arch-independent binary-indep vs binary-arch:
- only build the indep part once
that's pure debuild, not CDBS, Debhelper, or Dh
The copyright file
- Have all licensing info in one place, where everyone can find it.
- upstream software and license of packaging itself
The control file:
- format is vaguely RFC822
- "paragarphs", source, binary
note: single source -> multiple binary packages, namespace is separate, but convention is that 1-to-1 packages have same binary and source names
- maintainer vs original maintainer; teams in Ubuntu
Source and Maintainer are the only required fields in the source paragraph of the control file.
Binary paragraph: Package name: (need not be the same) Architecture: any (but must be compiled for each) vs all (works on all) Description: multi-line values must be indented on subsequent lines
- single space indent can be re-flowed
- 2 space indent must be displayed as is
- single dot on a line indicates blank line but not field break
Depends:
- explicit dependencies, must be installed
- shared libraries (shlibdeps)
-- ldd example -- dpkg-shlibdeps, uses ldd, then looks for packages, subs them in
- version dependencies, dpkg --compare-versions, etc, logical OR, etc
--- don't put in deps by hand if thye're purely shared lib dependencies, dpkg will deal -- disjunctive dependencies ("OR") --- APT looks through package list to see if any of the packages are installed. If they do, success. ---if not, look at beginning of list, try to install that, if succeeds, success. If not, try next. ---don't misuse them for optional deps (e.g. foo | basefiles), because basefiles will always satisfy it, and it'll never try foo.
Recommendations:
- attempt to satisfy, but don't fail.
Suggests:
- metadata only
Do not depend on "Essential" packages, unless you need a specific version
List of dependencies should be what _you_ need/interact with. e.g. If you need 'a' and 'b', and 'a' depends 'b', you still need both, don't just dpend on 'a', because it might change. Simultaneously, if you use 'a', and you _know_ that 'a' dependss on 'b', but you're not using 'b', don't depend on 'b'. Yes, this means that if you depend on 'a', and 'a' screws up their packaging, it won't work, but that's their problem.
Build-Depends: Things needed to _build_ the package, but not to _run_ it. But don't build-dep on a C compiler, because there are build-essential packages. /usr/share/doc/build-essential.list
SESSION 2
Quiz: List some arch all/any packages.
Which rules targets must be run as root/fakeroot? Difference between build-depends and depends.
Maintainer scripts:
- preinst, postinst, prerm, postrm
- all shell scripts, called in a variety of ways -- some take the _new_ version as args, others take old version
- talking about fixing up from previous screwups
- giant case statement, you should use the dhmakeexample
Talk about dpkg transactions, remove vs purge. link to order of transactions diagram, and link to policy
Idempotence. The postinst is quite likely to be run multiple times. talk about "set -e" doesn't _have_ to be in shell, but should be.
shell idiom " :" (if this fails, don't error out) ( true is more readble and equal nowadays) "something [ $? = 123 ]" so if something returns 123, it's not an error, but other error codes might be
Debhelper: -hello vs hello-debhelper
dh_foo, each one corresponds to a step -- abstract concrete tasks, e.g. dh_compress will compress what needs to be compressed
Also, the presence of some files (e.g. .install, .dirs) will trigger these operations or act as input for them. TODO clarify this.
Example of debhelper utilities:
- dh_ \[tab complete]
- dh_install*
- dh_install -- copy files into package -- cannot be renamed -- .install files -- list directories without prefix (TODO: check that we need to and/or still should) -- not difference for multiple binary packages
- dh_installcron (cron.d, cron.hourly, etc)
- dh_installinit (possible aside on init scripts, etc) -- also calls update-rc.d to "install" init script, by modifying your maintainer script
- dh_link (while simple, symlink policies) -- e.g. pine->alpine via alpine-config
- dh_fixperms
things that sanity-check the build process: e.g. dh_testroot
features:
- dh_shlibdeps
- different from dpkg-shlibdeps because it will find all binaries for you
DEBHELPER token in maintainer scripts (Lintian will warn if you miss it)
Show example of /var/lib/dpkg/info/(maintainer script) vs actual maintainer script in source to demo debhelper-added snippets
CDBS
common debian build system
debhelper.mk - runs all the dh_foo things for you
classes vs rules e.g. class = autotools, python, makefiles, apache ant, etc.
rules = how to do things (config-package, quilt, debhelper.mk)
autotools.mk knows how to run configure, make make install, etc., but also knows to pass --prefix, etc. makefile.mk knows how to run make, make install
read the .mk files to know what overrides are available.
debathena development
Use dasource, because it deals with autogoo