Quoting Raphael Hertzog (firstname.lastname@example.org): > 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 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"
Description: Digital signature