Quoting Raphael Hertzog ([EMAIL PROTECTED]): > On Fri, 16 May 2008, Joey Hess wrote: > > Coming up with a complex set of requirements that everyone has to follow > > up front in their workflow[1] is not going to yeld the best results, and > > I think that's my core reason for disliking Raphael's proposal. Now, if > > you can come up with protocols/interfaces that can be used to > > publish/communicate patches, that are managed/generated in whatever way > > is most useful for the maintainer, that seems more likely to work. > > Aren't "patch files in debian/patches/ with some headers" a defined interface?
I follow this discussion from quite far (because most of the times it
goes over my head particularly when dealing with VCS stuff), but I see
Raphaël's proposal to be quite similar to what we do for samba:
- have a debian/patches directory
- add pseudo headers to those patches with stuff like:
Goal: Prepare the sources to better respect FHS
New configurable paths are introduced in fhs-newpaths.patch
This patch associates files with the new paths
This part is debated with upstream
Fixes: #49011
Status wrt upstream: Meant to be forwarded upstream (a good rationale
about FHS is probably recommended)
Note: Use dedicated directories for:
- discardable cache data (/var/cache/samba):
browse.dat, printers.tbd, <printer>.tdb
- non discardable state data:
all TDB files that may need to be backed up
- shared data (/usr/share/samba):
codepage stuff
This patch needs work to be cleaner wrt people who want to run
multiple instances of samba
The patch *must* be reviewed after every new upstream release.
FAILURE TO DO SO MAY RESULT IN DATA LOSS FOR OUR USERS!
export QUILT_PATCHES=debian/patches
quilt push fhs.patch
grep -r lock_path source/ | grep -vE \
'"((brlock|connections|gencache|locking|messages|notify|sessionid|unexpected|wins)\.tdb|namelist.debug|lang_)|char
\*lock_path|WINBINDD_PRIV_SOCKET_SUBDIR'
- This will get you the list of any new, unexpected references to
lock_path. The files mentioned above are the known good uses of
lock_path; everything else needs to be investigated.
- If the file name occurs elsewhere in the fhs.patch, update the
patch to fix these new references to the same place (either
cache_path or state_path)
- If the file is a tdb file, and the code that opens it uses
TDB_CLEAR_IF_FIRST, lock_path is correct; just update the query
above with the new filename, no other changes are needed.
- Otherwise, if this is the first use of the file, you must
determine where the file belongs -- i.e., whether it's
persistent data, a cache, or runtime-only data. Consult
upstream if necessary.
- Repeat these steps for lp_lockdir(), which is less common but
still used in the code.
grep -r lp_lockdir source/ | grep -vE \
'%s/smb_(tmp_)*krb5|source/(lib/util|param/loadparm|dynconfig|utils/testparm)\.c|WINBINDD_PRIV_SOCKET_SUBDIR|(directory_exist|mkdir)\(lp_lockdir\(\),|koplock\.%d|%s/sync\.%d'
Index: samba-3.2.0pre3/source/lib/util.c
===================================================================
--- samba-3.2.0pre3.orig/source/lib/util.c
+++ samba-3.2.0pre3/source/lib/util.c
.../...
As one sees, we have 4 pseudo-headers:
Goal: describe what the package is meant to do
Fixes: what Debian bug it fixes
Status wrt upstream: reported or not ? Sometimes mentions "Debian
specific" for cases where there is no point in
applying it to pristine upstream (for instance
when we patch manpages to say "In Debian,
blahblah"
Notes: more information (in this specific case, how to refresh this
patch which is tricky)
So far, this has proven very useful for the duty we have to forward
such patches to upstream. Several of these patches are marked as
"forwarded upstream as Bug #nnnn"
signature.asc
Description: Digital signature
