As I was searching for various patches at ftp sites, I got struck by
how many different names patches get --- and how many different
versions there are. For example, there are 5 different versions of
the big-todo patch, and as a test, I'd ask the maintainers if they
know offhand under what name they are posted at their (or others') ftp
site.
Often happens that the name does not suggest uniquely what package the
patch is supposed to patch (like `rbl.patch' could conceivably patch
at least three packages).
So I was thinking, perhaps a modest version control could be
implemented: each patch file could have a name of the form
package-packageversion.patchname.patch
where the patch is supposed to patch package.
Like
qmail-1.03.big-todo.patch
Perhaps, the patchname could be followed by a version number (integer
is good enough), like
qmail-1.03.big-todo-21.patch
Similar conventions could be used for patches in tarballs, like
ezmlm-0.53.idx-0.322.tar.gz
(in this case, just kidding).
Since the patches are mostly posted to this list, it is probably not
difficult to keep track of the patch versions. The best would be,
perhaps, if there was a maintainer of each patch, and people would
send their version to the maintainer. (A higher version does not
necessarily mean improvement over a lower version, but a changelog would
keep track who submitted which version)
Finally, I found myself looking through all the patches to see if I
have to use -p0, -p1, etc. I found two cases where I could have gone
either way: in the same patch file, I saw
qmail-1.03.orig/dns.c
qmail-1.03/dns.c
[...]
install.orig
install
There was one patch to call for -p4.
I know, none of the above problems are outrageous, but one can spend
considerable time on sorting out badly organized patches. (Sorry, for
picking on the big-todo patc, but I still do not know, which one is
the latest, www.qmail.org's or Bruce G's.)
Sorry, for intruding
Mate
