Fink:Global deb scripts

I have a patched dpkg package, with support files in a new base-filesdpkg-base-filespackage, that implements global script hooks for the {Pre,Post}{Inst,Rm}Script blocks. If the a certain system-wide script exists, dpkg calls it rather than the one in the .deb. This global script is passed data about the dpkg action that triggered it and can do anything a normal .deb script can, including cleanup/patching of installed files to implement new fink policy, manipulating on-disk caches of installed files, etc. The last action this script takes would be to run the actual .deb script (if one exists), so the global scripts can also set env vars or pass other data to the .deb script as necessary. It steals ideas from the "triggers" feature present in "much newer dpkg than fink presently uses".

Specific ideas:

• Clear out dependency_libs after installing a .la file to solve problems caused by 10.6 (and especially 10.6 X11) no longer shipping them. This also cuts down on inherited builddepends (but also makes it harder to detect indirect builddepends that are still required; occasionally packages forget to pass required -l flags but work because .la publishes them, which will become a visible build error).
  1. dpkg-base-files has a PostInstScript that fixes all presently-installed .la files (so user's existing system comes up to standard).
  2. dpkg-base-files PostInst global hook fixes .la files of packages per the standard when they are installed
  • What is the best-practice fix to use? Just deleting .la seems overkill and there is a report that one package actually needs them. Fink's solution cannot break things and must be as conservative as possible--whatever it does will have lasting effect forever once implemented. Safer solution (pogma says this looks fine):

    perl -pi -e "s/^(dependency_libs)=.*/\1=''/"

  • Better to have a single script that is called both by PostInstScript and the global PostInst hook, or to hard-code the scriptlet into those places directly?
  • How does a PostInst of a package learn what files are being installed as part of that package?
• Load init.sh before the .deb script runs to solve the problem that the scripts are not necessarily run from a shell that has fink's env vars set. This is a long-standing surprising "feature" of these .info script blocks that causes hard-to-diagnose failures.
• Externalize/centralize certain PostInst tasks that require lengthy cut'n'pasted boilerplate in .info (example: gconftool). Trade-off maintainer-vs-user pain: loss of ability for validator to check "using gconftool therefore needs Depends:gconf2", but could still look for its data files (the global scripts could be made to crash with specific error message if missing gconf2 but they could not themselves have the depends because dpkg-base-files is lowest-level dep in fink).

Issue: what is the dependency chain (new-dpkg:Depends:new-base-files vs new-base-files:Depends:new-dpkg)? new-dpkg is safe if old-base-files (or if new-base-files does not supply a certain global hook)...just calls the .deb script directly (fallback to previous standard behavior). If base-files->dpkg, other pkgs can specify versioned dep on base-files if they need certain features implemented in it without also having to specify dependency on dpkg that handles global hooks ("any base-files that has hooks requires dpkg that calls the hooks" makes sense). But need drm to tell us about bootstrap order-of-build/installation to make sure we don't deadlock or have circular deps (make sure it's not a problem to have dpkg installed very soon after dpkg-bootstrap, etc).

• Update: dpkg sits on top of several packages including libraries, and at least one of these deps has Depends:base-files...cyclic:( If the bootstrap order is "dpkg-bootstrap; dpkg's deps; dpkg (which displaces dpkg-bootstrap)", could have base-files:Depends:dpkg|dpkg-bootstrap if dpkg-bootstrap also got the global-hooks hack.

The wrapper/hooks are in "dpkg-base-files", which Depends:dpkg so packages that want the wrappers can Depends:dpkg-base-files and they will work, and gets us out of a dependency loop. Thanks drm!

How to get it:

• "dpkg" package in dmacks's CVS exp:

Get the latest dpkg.info and dpkg.patch files, place them somewhere in your fink dists trees, run fink update dpkg

• "dpkg-base-files" module in fink CVS:

cvs -d:pserver:anonymous@fink.cvs.sourceforge.net:/cvsroot/fink co dpkg-base-files
cd dpkg-base-files
./inject.pl