quilt-dev
[Top][All Lists]
Advanced

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

[Quilt-dev] Re: Holger's patch mgmt. script (patcher, Perl)


From: Andreas Gruenbacher
Subject: [Quilt-dev] Re: Holger's patch mgmt. script (patcher, Perl)
Date: Thu, 30 Jan 2003 17:57:01 +0100
User-agent: KMail/1.4.3

On Thursday 30 January 2003 16:44, Holger Schurig wrote:
> > * Allows to work from within a sub-directory of the working tree.
> >   [Do we want that?]
>
> This is a TODO feature, it's not fully tested.
>
> The search for the .patches directory works already, but other parts
> haven't been tested.

I see.

> By the way: I only have one directory (.patches) instead of three.
> That makes it less intrusive. And there was no real need for the old
> .txt vs. .pc directory, because all files in it ended in with
> different extensions anyway.

The txt/ directory and .txt files are entirely gone in Quilt, too. The 
documentation is simply kept in the patch files themselves, which is no 
problem at all. The pc/ directory has been renamed to .pc; it only 
contains data that can be discarded anyway. The patches/ directory 
still remains, it contains all the patches. It should be possible to 
move it to another directory using an environment variable, though.

> > What I dislike:
> > * Monolithic script, more difficult to extend.
>
> Why is this difficult?   Just add your subroutine.

I am simply not going to use a monolithic design. How would you add 
things in non-Perl, etc.?

> Okay, I confess, the option handling near the end of the script is
> not so easy to get, it deserves a re-writing.

I've not not understood the script.

> Hmm, I have one idea. Using some perl-magic it should be possible
> that patcher behaves as a main program if called directly. And as a
> perl-module if called via "use patcher". This way anyone can write
> out-of-patcher scripts that can make use of the infrastructure laid
> down in patcher.
>
> > * Keeps some of the crappy parts of Andrew's scripts.
>
> What do you mean?     I'd like to hear what you've done better in
> your current incarnation of quilt :-)

I told you some improvements in a previous, personal mail already, but 
here you go again.

        * The "a~b"-Files have moved to ".pc/b/.../a".
        * fpatch ist now split into "quilt new" and "quilt add".
        * Refresh of arbitrary patches works, not only the topmost.
        * There's a check which patches modify a given file.
        * Set up the working directory directly from an RPM spec file,
          or from a series file (quilt setup).

> > * Substitutes a bunch of scripts against a load of command line
> >   switches. Not nice.
>
> Again, the GOAL was to have one file to rule them all. :-)
>
> So, it is by definition a NICE design :-)

Not nice master. Ssilly design.

> Here again we can do some ARGV[0] magic and let the script behave
> differently when called with various names. So, if some really want
> to have twenty scripts, then one can ln -s patcher pt_import, ln -s
> patcher pt_apply and so on. That would be the "busybox" way.

This does't improve the overall design in any way.

> Or I go to some cleaner way of structuring it, like "cvs" or "bk" do 
it right now.
> Hmm, I have one idea. Using some perl-magic it should be possible
> that patcher behaves as a main program if called directly. And as a
> perl-module if called via "use patcher". This way anyone can write
> out-of-patcher scripts that can make use of the infrastructure laid
> down in patcher.
> > * Quilt can already do several additional things.
>
> Hmm, I should download quilt so see what additional things it has ...

Go take a look. That will give you a much better idea of where we're 
standing now.

Cheers,
Andreas.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]