[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Problem (Is preinst really pre?)

Hash: SHA1

Steve Langasek wrote:
| First, if you use debconf in the preinst, you must have a Pre-Depends: on
| the relevant package (namely, debconf).  Second, if you do have debconf
| installed ahead of time, then yes, the preinst isn't actually as early as
| you want it.  You should do most of your preloading and prompting of
| values in a config script, which will be run first thing by apt if you
| have debconf installed, or from within the postinst script when you
| initialize debconf if it wasn't installed.
| The .config script follows the same basic rules as the rest of the
| maintainer scripts, except that it's intended specifically for debconf-y
| stuff.  Anything else should go in the {pre,post}{inst,rm}.

OK, So the debconf stuff should be handled in the config. The problem
is, it looks like the config is run in a semi-random order with the
configs of the packages that are also being installed (specifically, the
ones that this package depends on).

Simon Richter wrote:
| Why are you splitting up the package if they cannot be installed
| separately? Such splits only make sense if the amount of data the
| package needs warrants a separate arch-all package.

I'm not explicitly splitting a package up. I'm trying to automate
configuration of a number of packages through the use of a package of my
own design. I don't have any control over the other packages, as they
are largely from Debian or other third party packagers.

| Yes, because the preinst isn't even extracted at that point. All
| packages that are going to be installed are configured either before any
| of them is unpacked (if apt-utils is installed) or during postinst time
| (if apt-utils is not installed). I believe it is also legal at any other
| time in between (e.g. while the package is being unpacked in the
| background).

apt-utils is installed at this time, so this means that all configs will
get run at the same time? In this case, is there any other option to get
a script in my package to run prior to the config scripts in the other
packages, short of modifying the other packages to Pre-Depends on mine?
(not a great solution, since that would mean having to tinker with other

Version: GnuPG v1.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply to: