[Quilt-dev] quilt (was: patch-scripts)

[Martin Quinson]

Hello, I cced the mailing list I created yesterday for that use. Do you all
subscribed to it ?

On Tue, Jan 21, 2003 at 03:45:02PM +0100, Andreas Gruenbacher wrote:
> Hi Martin,
> 
> On Tuesday 21 January 2003 11:34, Martin Quinson wrote:
> > Hello all.
> >
> > - Document the fact that it's possible to create subdirs in patches/
> > and other dir (if I understood well Andreas's related changes)
> 
> Yes. That was required for a very large collection of patches (our 
> kernel).
> 
> > - You (AG) removed another functionnality I liked very much in AM
> > version: it was possible to put all patch-scripts directories in a
> > subdir, to make minimal the chance of dir name collision between the
> > patched tree and the one we use here.
> > Moreover, it made possible to
> > keep these directory in another location, and simlink from where they
> > live to where they were needed. It helps in dealing with a new
> > version of the patched tree.
> 
> That feature is still there, by setting the PATCHSCRIPTS environment 
> variable. (Maybe it was accidentally missing in 0.11 though.) One 
> drawback: it is currently untested.

Ho. I did miss that. So the last point to solve before I can use your
version is the status stuff. But maybe did you also solve this point?

> I have renamed what before was the pc/ directory into .pc/. This 
> directory always lives in the source tree and cannot be moved. IMO 
> moving it would be dangerous for the scripts, and I think not 
> necessary.

The problem is that it prevent me to put the quilt serie in a freshly
untarred archive in one link... That being said, it's not a showstopper.

> > Here are a bunch of ideas for the future, extracted from the mails
> > Andrew forwarded me:
> > * [AG] We could put all informations in only one file, like:
> >
> >         Summary: Test patch
> >         Author: Andreas Gruenbacher <address@hidden>
> >         URL: http://www.suse.de/
> >
> >         %description
> >         DESCRIPTION
> >
> >         %files
> >         FILE1
> >         FILE2
> >         FILE3
> >
> >         %patch
> >         PATCH
> >
> > My opinion: It sounds cool, it just lacks a "target project:" field
> > at the begining, and maybe a "trajet project version" one, so that
> > it's easier to remember against what the patch is.
> > You say that the %files information is useless since it can be
> > retrived from %patch. So, what about a %diffstat one ?
> 
> The lib/parse-patch script (Perl) allows to select individual sections 
> from the patch (the unlabeled first section is accessible as `head') as 
> well as updating. As far as apatch and rpatch are concerned those 
> patches should should apply without any parsing, or else many people 
> will be unhappy with the patches produced. In refpatch I am scanning 
> for `%patch' in the file. If found I am assuming the above format and 
> refpatch only replaces the %patch section. Otherwise everything before 
> the actual patches is kept, and everything below what looks like the 
> beginning of the patches is replaced.
> 
> That should be all the patch scripts need to care about; except for 
> refpatch a richer format shouldn't have any influence.
> 
> If is also trivially possible to insert new sections into %sectionized 
> patch files using parse-patch. `cat ... | parse-patch -u new-section' 
> simply creates it.

I guess we'll have to speak about all this again once we managed that
everybody here use the same version of the scripts.

> > * [JR] Single script to cut down the forking.
> 
> I consider this harmful (more difficult to maintain), and not necessary 
> at all. The bottlenecks are not with forking; the scripts are quite 
> fast.

I did misunderstood what James said (sorry, I'm not native speaker).

> > * [JR] Improve error checking
> > I guess that Andreas's changes already improve it.
> 
> Yes, hopefully. Even SIGINT shouldn't cause havoc anymore.

And that rocks.
 
> > * [JR] Document all this.
> 
> Yes, that would be much appreciated.

I'll do that once we cleaned up this mess.
 
> > But before we can start hacking on that, I would say that we still
> > need a bit more organization. Could you create a new user account on
> > savannah and tell me which one you choosed, so that I can add you as
> > member of the projects ?
> 
> I am user agruen now.

And you are added to the project members, as admin.

> > I did ask for the creation of a
> > address@hidden mailing list, but it still needs a few time
> > until the cron tab create this. Afterward, could you subscribe to it,
> > or tell me that you're not interested in quilt anymore?
> >
> > Andreas, did you change your version since 0.11 ?
> 
> Yes, very very heavily. I also have a number of additional ideas, some 
> of which are probably very worthwhile. You can snapshots of my ongoing 
> work at http://www.suse.de/~agruen/patch-scripts/. Please look at the 
> TODO and BUG file in the package.
> 
> Also related to this project is another bug that I filed against GNU 
> patch, with (not very surprisingly) no reaction from anybody so far. I 
> am attaching the quick hack that I am using currently.

That's exactly what I feared, and why I didn't base much of new code in on
the version in the CVS.

> > If yes, could you commit this to the new CVS?
> 
> I am planning to do so, but before I really want to finish some of the 
> features most important to me. Then there will be a lot of hand 
> merging; the code really has changed massively in the meantime. Also I 
> want to avoid submitting controversial stuff, so we should discuss a 
> bunch of things first.
> 
> Alternatively you could re-seed the project with my current snapshot and 
> redo the changes; I would then try to immediately work against the 
> Savannah CVS. That could be a bit painful as I might accidentially 
> break things along the way, though.
> 
> Is there a way to upload a CVS repository to Savannah? I have a somewhat 
> chaotic CVS here, but with no proper tagging. It still gives some 
> change track, though.

Another solution is that you send me your working directory per email, and
promise me not to change anything in your version 'till I merged your
lastest stuff in the CVS.

Of course, this operation can wait until you're done with what you're doing
right now. Provided that it will happend before too long. ;)

Bye, Mt.

-- 
Un clavier azerty en vaut deux.