Re: Centralized darcs
Matthew Palmer writes ("Re: Centralized darcs"):
> diff.gz archaeology should not be necessary.
I think this is the root of the key difference between the `like patch
systems' people and the `hate patch systems' people.
`Hate patch systems' people are those who can read code, and prefer
programming and debuggint to doing archaelogy. They're people like
me: my first approach to any bug I'm trying to fix (or change I'm
trying to make) is to read and then edit the actual code. Only if I
seem to be explicitly going against some other person's decision, or
the whole thing seems crazy, will I try to find some archaeology or
changelog or something in an effort to find out why it was done the
crazy way.
`Like patch systems' people are those who would prefer to do
archaelogy to dealing with the actual code of a program written by
someone else. These are people for whom the average level of clue in
the world as represented by the history of the program and other
people's patches exceeds their own ability to generate correct changes
to the code. The resulting culture is one of `cargo culting' patches
and `explanations' from one place to another, without really
understanding them.
When I work on Ubuntu packages I'm basically doing NMUs all the time
and I have been forced into a completely insane workflow to deal with
the mad patch systems:
$ dpkg-source -x /export/mirror/.../program.dsc
$ mkdir orig build
$ rsync -a --delete --delete-excluded --exclude='*~' program orig/
$ rsync -a --delete --delete-excluded --exclude='*~' program build/
$ (cd build/program && debian/rules build && debian/rules binary)
now edit build/program/stupid/long/path/src/program.c to make
the bulk of my changes
test the resulting program in the build tree if possible
if I'm very lucky then I can edit program.c and
$ make -C build/program/stupid/long/path/src program
if I make a change but sometimes this is not possible and I have
to resort to the process below
$ diff -u build/program/stupid/long/path/src/program.c{~,} \
>program/debian/patches/999_my_new_patch
now edit program/debian/patches/999_my_new_patch
$ grep -R 888_some_existing_patch program
this tells me whether 888_some_existing_patch needs to be added
to a list of patches and if so I edit the list file
also edit program/debian/changelog
$ rsync -a --delete --delete-excluded --exclude='*~' program build/
$ (cd build/program && debian/rules build && debian/rules binary)
not that this is a complete rebuild. I use ccache.
$ really dpkg -i program.deb
run test
if test does not work, edit 999_my_new_patch and rebuild from scratch
if test does work
$ diff -ruN --exclude='*~' {orig/,}program >diff
and send diff to bug system.
This is incredibly clumsy but it has the virtue of being reliable and
not requiring me to learn dmadpatch 0.37 as distributed in program
0.0.0.3 from 1999 and not having to deal with any bugs in patch
systems etc.
But, FFS!
Ian.
Reply to: