[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to handle Debian patches

Quoting Raphael Hertzog (hertzog@debian.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[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.

      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 \

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,
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"


Attachment: signature.asc
Description: Digital signature

Reply to: