Re: patch filenames

[Dieter Baron <dillo%danbala.tuwien.ac.at@localhost>]

In article <1A0334EC-7DF9-4644-94B0-28473E0CA86C%gmail.com@localhost> Julio 
wrote:
: On 06/01/2008, at 0:50, Roland Illig wrote:
: > I'd like to change the filenames of patch files, since the naming  
: > scheme patch-[a-z][a-z] doesn't give me enough expressiveness for  
: > efficient work.
: >
: > We already had a discussion about this topic in June and July 2004:
: >
: >     http://mail-index.netbsd.org/tech-pkg/2004/06/
: >     http://mail-index.netbsd.org/tech-pkg/2004/07/
: >         ([change request] pattern for patch filenames)
: >
: > The discussion revealed that there are some different opinions of  
: > how patch files should be named, but arguments for a specific  
: > scheme were rare, and suddently the discussion ended. We had these  
: > suggestions:
: >
: > 1. Keep everything as is (patch-[a-z][a-z], one patched file per  
: > patch):
: >
: > [pro] simple, easy, and it works.
: > [pro] short filenames, viewable even on small screens.
: > [pro] the order in which the patches are applied doesn't matter.
: > [con] CVS history contains comments on many unrelated patches.
: >
: > 2. Filename based on the patched file, one patched file per patch:
: >
: > [pro] patch filename shows which file is patched.
: > [pro] the order in which the patches are applied doesn't matter.
: > [pro] CVS history contains only changes to this particular file.
: > [con] the name of the patched file occurs three times: in the  
: > filename, in the "---" line, in the "+++" line (redundancy).
: > [con] there's a naming scheme to be learnt

  And to be defined.  Roland: That part is missing from your proposal;
could you please suggest a naming scheme that

  1. does not cause problems on handicaped file systems (e.g. case
     insensitive or Windows that disallows `:' in file names
  2. maps file names uniquely into patch file names (so the same patch
     file won't be reused for different files)
  3. is easy to remember and apply?

: > 3. Group functional changes into one patch file:
: >
: > [pro] the patch can be easily removed once the problem has been  
: > fixed upstream.
: > [con] a file may be patched by multiple patches. The order in which  
: > the patches are applied becomes important.
: >
: > I'd like to establish variant 2. (I don't want to displace variant  
: > 1, I just want to be allowed to use variant 2 for packages I  
: > maintain.) Other opinions?

: Except that 3 makes it much easier to feed things back upstream,  
: while 2 does not at all when you patch a single file for multiple  
: different reasons (being configure the most common example).

: To solve the order problem, we'd add a "series" file alongside the  
: patches that lists the patch names and thus imposes order among  
: them.  Then it'd be trivial to use quilt to manage these patch sets,  
: which is a pretty nice tool when you get used to it :-)

  pkgsrc is complicated enough without adding extra complexity with
patch handling.

  Currently, the .orig files contain the original version of the file,
and tools like pkgvi and pkgdiff can do their work.  Julio: How do you
propose to deal with that when patching one file multiple times?


                                        yours,
                                        dillo