[Top][All Lists]
[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.