[Pkg-shadow-devel] Policy for patches in the sid branch

[Nicolas François]

On Thu, Apr 14, 2005 at 07:06:14AM +0200, Christian Perrier wrote:
> Quoting Nicolas François (nicolas.francois@centraliens.net):
> >  * This dpatch will depends on the 1xx patches, so I had to create a
> >    00list file in debian/patches.
> >    Should this 00list file be present in the CVS?
> 
> Yes, if I understand well its purpose. Could you quickly elaborate?

see below

> >  * The header of the dpatch generated by dpatch-edit-patch looks rath=
er
> >    different from the ones in the debian/patches directory.  Does it
> >    depend on a configuration variable (maybe a 00template file)?
> 
> All files in debian/patches are manually generated..:-). I know, I'm
> dumb, this is a very well known fact...
> 
> I'm not even very clever about dpatch tools as my only goal was
> getting together these patches so I took one package using dpatch as
> example, but indeed I'm not deeply familiar with these tools.
> 
> So, it doesn't matter if the header is different. And, please, feel
> free to document your use of dpatch to produce nice patches in
> README.patches..:-)

It was the first time I used dpatch, so it is not necessarily _the_ way to
use dpatch.

Here is how I generated the patch:
 * extract shadow_4.0.3.orig.tar.gz
 * put the debian directory from the Sid branch inside the shadow-4.0.3
   directory
 * create a dumb 00list file:
for i in debian/patches/*.dpatch; do echo `basename ${i%.dpatch}`; done > debian/patches/00list
 * prepare the creation of the new patch:
   dpatch-edit-patch patch 314_lastlog_usage_249611 131_tl
   (as the 314_lastlog_usage_249611 does not exist, this means
   dpatch-edit-patch will create a new dpatch, 131_tl indicates that I
   want all patches up to 131_tl to be applied)
   (this step required the 00list file)
   
 * a new temporary directory is created and a new shell is invoked
   in this directory (by dpatch-edit-patch).
   I'm doing my modifications there.
 * then I exit from this new shell
 * and dpatch-edit-patch automagically creates the
   314_lastlog_usage_249611.dpatch file in debian/patches, with the
   changes performed in the temporary directory.

If I want to edit this patch, I can:
  dpatch-edit-patch 314_lastlog_usage_249611
This will create a new temporary director, invoke a new shell, etc.
An regenerate the new patch after this new shell exits.

dpatch can also be used to
  * apply all patches (00list required):
    dpatch apply-all
  * get a status (know which patches are currently applied:
    dpatch status-all


I was not used to dpatch, so I though that was the way to use dpatch.
But, according to your answer, a dpatch can also easily be edited by hand.


> > Do we commit new patches (in the Sid branch)?
> > (I'm asking this because it will break the equivalence with
> > 4.0.4-31sarge2).
> > I would anyway rather like a review for my first dpatches.
> 
> Well, if all things that break the equivalence with 31sarge2 are
> numbered in a way which easily allows to remove them before building,
> this is not a problem.

CVS sucks when it comes to renaming a file. The special numbering will
have to be kept post-32.
Maybe we can just keep in mind that some patch should not be applied for
the equivalence with 31sarge2, or document it in the patch.

Maybe we could just list the patches for 31sarge2 in 00list, so that
dpatch apply-all will generate 31sarge2, and applying all additional
patches not present in 00list would generate post-32.

> We should find a way to handle debian/changelog, however. At this
> moment, it has the 3xx patches listed, but if we first build a -32
> version which is only a "switch to dpatch" version, we will have to
> edit it and keep the post-32 stuff elsewhere temporarily.
> 
> Maybe a debian/changelog-post32 file would be better?

I modified the changelog in the patch.  But now I think it wasn't a good
idea (it force the application of the the dpatch in the right order).
A temporary debian/changelog-post32 seems better.

> > > In short, while we are working towards synchronisation with upstrea=
m,
> > > our goal is to make 0xx patches disappear by moving them either to =
3xx
> > > series (things already implemented upstream) or to 4xx series
> > > (Debian-specific patches).
> > 
> > I think you mean splitting 0xx patches to logical sub-patches.
> > Do you recommend a way of using dpatch tools for splitting the 0xx
> > patches?
> > Here is how I intent to do this:
> >  * De-aply the 0xx patch (only one, all, some)
> >  * create a new dpatch and pick some of the changes
> > (* update the 0xx patch(es) involved in this logical sub-patch)
> 
> Yes, that's more or less the way I think we should work. Indeed, being
> dumb, I imagined doing this manually, starting with the manpages patch
> probably (one man page patch per dpatch file).
> 
> But, you certainly have better ideas there, so feel free to apply them.

I don't have any idea, but I will apply them ;)

> > Another points non related to dpatch:
> > The debian changelog seems to contain lines starting by a tabulation.
> > My beloved vim seems to choke on these lines (colored in red).
> > Maybe these tabulations should be expanded.
> 
> Yep. I'm not good at keeping consistency here. Again, feel free to
> clean up my mess.

I didn't know why vim colored these lines in red (usually it means a syntax
error).
I found this:
(http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog)
    "The change details may in fact be any series of lines starting with
    at least two spaces, ..."

> > Would you like to have CVS commits notifications?
> 
> You mean automated CVS commit notifications in the list or just manual
> mails from you when you commit something?

I was thinking about the first one (notifications in the list, or in a
new -commits list).
I will anyway (try to) notify the list if there is no automatic
notification.

Regards,
-- 
Nekral