Re: Packaging phpLDAPadmin. Newbie's questions.
On Thu, Nov 13, 2003 at 09:51:22PM -0600, David Segonds wrote:
> On Fri, Nov 14, 2003 at 10:46:35AM +1100, Matthew Palmer wrote:
> > What's to heavily modify? I presume the config file is a fairly reasonable
> > format, in which case a search 'n replace for 'config_option\s=.*$' to
> > 'config_option = <new value>' would appropriately modify the file to suit
> > your needs.
> The default config file looks like this:
> conf[$i]['host'] = 'foo' /* A comment */
> conf[$i]['port'] = 'bar' /* A comment */
> conf[$i]['host'] = 'whatever1'
> conf[$i]['port'] = 'whatever2'
Eeeeeww! I'll have a crab juice!
> In this case, the same entry appears multiple time. I need to change
> the config file so it fits my needs by replacing '$i' by '0' for the
> first instance. I also need to move the comments to separate lines. It
> is not a hard job, I just don't keep the config file from upstream and
> that is not a big problem.
Yeah, I'd have a bit of a fiddle there, make it slightly more sane. Seems
like it could do with it...
> > [md5sums on conffiles.]
> I like that. This is a good idea and fairly simple to implement. In
> which package can I find an example of this?
IRM in unstable has this. I'm hoping to push it to phpwiki, and perhaps
put the functionality into a package (existing one), but it's only a couple
of lines of shell script - hardly likely to be ground breaking stuff. <g>
> > > Is it a common practice to modify a configuration file by adding keywords
> > > and placeholders so upgrades and reconfigure run smoothly?
> > It's done, but it's by no means recommended unless you can't avoid it.
> So basically, you don't keep track of user changes and make sure that
> their modifications stays.
No, I didn't say that. What I took your question to mean was something like
### DEBCONF SECTION ###
// All sorts of debconf-set variables
### END DEBCONF SECTION ###
and then your maintainer scripts go and walk all over anything in the
debconf section, and leave the rest alone. That's done by various packages,
but it's not suggested practice.
If you mean producing a template file with tags which you macro-replace at
configuration time, that's also done, and works well enough if combined with
something that ensures that the user's config file doesn't get blotted if
they want to fiddle with it themselves - so the md5sum idea above can be
> What happen when new configuration parameters appears in a new upstream
> release? I guess you can stuck them in there without touching the rest
> of the configuration? You can warn the user about it too.
You can add it to the end of the file, or rewrite the file a bit, or
Honestly, config file handling is a serious bugbear, both in Debian and in
general. It's hard to do it so that the user can have their own changes,
and the maintainer can do his own thing too without fear of breaking
The best way I've thought of is to always have two (or three, in the case of
user-run applications) config files - "distribution", "system", and possibly
"user" files. All the same thing, just each one overrides settings in the
previous one. So, the maintainer script is free to fiddle with anything in
the "distribution" file, and if the user fscks with that, then they're an
idiot. Then there's a system one, which the maintainer or local
(non-debconf) config program might change at will, and then a per-user
config file for apps which need to be configured per-user.
For PHP apps, the best way to go is just to source each one of those, in
order, (or the first two, anyway), so that the system config options
override the distro ones if both are set.
Don't know if it's of any use in your case, but I thought I'd espouse my
thoughts - might be of use to someone.