udo_richter@gmx.de(Udo Richter) 01.06.05 19:48

Rainer Zocholl wrote:

...

can't patches modify/add a string to a "Versionstring table" too, which VDR logs in syslog and (maybe) displays in the command window?

Problem is: How to avoid collisions of different patches if they want to write to the same 'installed patches' list?

Only idea I have would be an installed-patches sub folder where every patch can place an unique-named file with an ID string. Then you just need a clever makefile that merges all these together into one include-able file.

Can make depend a file on every file in a sub folder? eg. does something like this work:

installed-patches.inc: installed-patches/* @cat installed-patches/* > installed-patches.inc

assuming the degree of garbage in teh VDR folder is ninimal, such a simple script could be used: (Of course it would be more elegant if "depend" generates an exactfittung list)

#!/bin/sh

# very frist script FILE=cvs_revs.h FILETMP=$FILE.tmp mv $FILE $FILE.old

rm -f $FILETMP echo "/* Automatically generated by $0 */" > $FILETMP echo "static char* CVS_ALL[] = {" >> $FILETMP grep "^* $Id: .*$$" *.c *.h | sort | awk '{ print "/* Filename",$1" */","\n" """$2,$3,$4,$5,$6,$7,$8,$9,$10""," }' >> $FILETMP echo "NULL };" >> $FILETMP

diff $FILE.old $FILETMP if [ $? -eq 0 ] ; then echo no change mv $FILE.old $FILE rm $FILETMP else echo change mv $FILETMP $FILE rm $FILE.old fi

run in the VDR directory generates the file cvs_revs.h:

static char* CVS_ALL[] = { /* Filename audio.c: */ "* $Id: audio.c 1.3 2005/02/12 12:40:51 kls Exp $", /* Filename audio.h: */ "* $Id: audio.h 1.3 2005/02/12 12:20:19 kls Exp $", /* Filename channels.c: */ "* $Id: channels.c 1.42 2005/05/29 10:32:38 kls Exp $", ... etc.. NULL };

This file may be include into "vdr.h" or "vdr.c" The "redundant" "/* Filename audio.h: */" is to give "patch" some fix points for "fuzzy" logic, as this file might have many changes. At least i hope it may help...

VDR may run a loop like:

{ #include "cvs_revs.h" /* for CVS_ALL */ int i; for(i=0; CVS_ALL[i]!=NULL; i++) nvprintf(LOG_DEBUG, "%s\n", CVS_ALL[i]); nvprintf(LOG_DEBUG, "Built at: " __DATE__ " " __TIME__ "\n"); }

writing into syslog when it starts togehter with it's own version number.

There are two ways a patch can indicate it self it was applied:

If a patch is applied it could add it's own "Id$: patch" to the modified source file. Or it changes the CVS $Id. At least that would be fair to do...

The "make" calls the above script and generate the new include.

instead of "grep ...*c *.h" a "find" may be more usefull, as it can go recursive thru the directories.

Too the files date might be included if the "patch" forgat to change or add an Id.

The code was taken from Sergeis Haller "nvram-wakeup"

Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------

udo_richter@gmx.de(Udo Richter) 02.06.05 21:24

Rainer Zocholl wrote:

...

The "redundant" "/* Filename audio.h: */" is to give "patch" some fix points for "fuzzy" logic, as this file might have many changes.

A diff -u needs at least three common lines before and after each change to pass through with 'fuzz'. And because this is a generated file, no patch should change it.

Or take as "base" and add new lines. But then it can't be generated anymore.

In fact, it will be a common mistake to include this file in patches.

Yes.

...

If a patch is applied it could add it's own "Id$: patch" to the modified source file. Or it changes the CVS $Id.

Again, if two patches try to modify the same source file, they MUST collide, because both want to change the $Id line.

So there would be only to "add" a new "ID"

Then we'll be in patching hell, because patches will require proper ordering and depend on each other. (... patch X for plain vanilla VDR, patch X.1 for users of patch Y, patch X.2 for users of patch Z, patch X.3 for users of patch Y AND Z, ...)

Don't we have that already?

Does current patches do not change the ID or add a new?

The only way that wont introduce unnecessary conflicts is to add NEW files,

True.

like installed-patches/MyPatchName.info, and then collect all these info files somehow.

However, first, this requires such a method to be implemented in VDR, so you need Klaus to do it,

or make a patch for it? ;-)

and second, all patches must be adapted to support this.

"Should"... I assume the patcheers will do it on their own interresst, because they too would like see if the patch worsk with others or not.

An other way would be simply note the source file date and size (or md5 ;-)) to see which files were changed compared to the tar.

You really think this will work?

As the number of patches are still growing it will become harder and harde to reproduce errors. Do you always know exactly which patches were manually applied, say 3 weeks later...i wouldn't. Maybe VDR needs someday something like a mini-apt (iapt)? ;-)

Anyway: Does it really help debugging or to make VDR more stable to have more transparency?

Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------

udo_richter@gmx.de(Udo Richter) 03.06.05 02:52

Rainer Zocholl wrote:

...

...

Then we'll be in patching hell, because patches will require proper ordering and depend on each other.

Don't we have that already? Does current patches do not change the ID or add a new?

I currently use 5 patches regularly, with no collisions and no patch ordering dependencies. 3 of the 5 patch menu.c without collisions.

That may not fit for every one.

None of them adds any kind of ID string.

Not so nice, IMHO. But avoids collisions...

...

Do you always know exactly which patches were manually applied, say 3 weeks later...i wouldn't.

Actually... My VDR + plugin sources are built from the tars by a prepare script so I can always reproduce the current code base, and I can easily upgrade to newer versions without loosing anything.

Somewhere to download the script?

I can reconstruct every major version I've used since end of January.

Actually i thought more in the direction someone else "outside" should be able to reproduce the version (at least be able to see: "Was patched with xxxx but the user forgot to mention!") and that it should "be documented", not that actually yourself might have the problem... Too i don't think that everybody first makes a script before trying a new patch. But i do think that someone is likely to forget the patch he did manually.

Rainer