The problem is most definately that the ports are already in use by the host system (you mentioned you are running LAMP). So, just stop the services on the host system prior to running the tklpatch conf script.

BTW, the example drupal5 conf script starts and stops both MySQL and Apache.

What is the "host" system when you "run" the drupal patch ?

I'm pretty sure that the "start" will work as long as there is no same daemon run in the Host system. So ... make sure to stop daemons before tklpatch-apply

c/q Liraz and Alon.

I think it'll be good if tklPatch have some mechanism for environtment-precondition. May be you can consider a conf.pre .. that is a script that will be called before calling the conf script ?

 Sincerely
-bino-

Dear Liraz.

First I Apologize for my bad english.

"conf" is a script that tklpatch-apply will run after it do "chroot"

So, i thing it'll be good if there is a place that we can put a script that will be called by tklpatch-apply *before* it do anything else.

Also it'll be great if there is a place that we can put a script that will be called "after" it finish "conf".

 

May be something like :

patch-dir/conf.pre

patch-dir/conf

patch-dir/conf.pos

 

i.e :

conf.pre

#!/bin/bash

/etc/init.d/postgres stop #Kill pgsql of dev host

conf

#!/bin/bash
/etc/init.d/postgres start #start the pgsql of target-iso.rootfs

 #any procedures

/etc/init.d/postgres stop #kill the pgsql of target-iso.rootfs

conf.pos

#!/bin/bash

/etc/init.d/postgres start   #start the pgsql of dev host

Sincerely

-bino-

We can't do what you propose because it violates a well known programming principle: separation of concerns.

In other words, by adding conf.pre/conf.post scripts we would be tying the logic of tklpatch to the specifics of the host running tklpatch. We know this is the wrong thing to do because it makes assumptions about the host that is running tklpatch (e.g., that it is running a particular set of daemons).

If you are using a development VM the correct solution would be to just disable the services permanently. Otherwise maybe add a couple of adhoc scripts (e.g., tklpatch-pre tklpatch-post) to /usr/local/bin which prepares your system for development.

BTW, you don't need to apologize for your English!

Dear Liraz.

I'm sorry if it a violation.

But what I mean with that conf.pre/conf.pos is just "a place to put" the script. Just like what "conf" for.

So it'll not a mandatory for coder to put anything inside, but when He/She need to .. there is a place.

From my experience while learning tklpatch, I'm focusing on how to writhe the conf script.

Once it's finished, I try tklpatch-apply .... and I found that since my conf script need to start pgsql of target-iso.rootfs , I need to kill the dev host pgsql first.

Since I'm not a good scripter, I need to edit the conf script over and over ... re run tklpatch-apply over and over. Most of the time, I remember to kill pthe pgsql first, but there is also times tht I forgot.

It's Ok As a patch developer (although a newbie developer) I have to remember to kill dev host pgsql first. But what about "patch user" ? Do we want them to also remember it ? while potentialy their knowledege of linux is as worst as me ?

Sincerely

-bino-