is there a standard way to get the g-b-s to apply multiple patches?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

is there a standard way to get the g-b-s to apply multiple patches?

Yitzchak Scott-Thoennes
I'm working on updating the fortune package and switching to use the
generic build script, but I'd like to have the source package to have
the original source, the current debian patches, and a separate patch
file with my patches.  The debian package maintainer is also the
maintainer of the upstream source, but he isn't updating that, just
letting the debian patches get bigger and bigger over time.  I'd like
my patches to be distinguishable from what's standard.

Reply | Threaded
Open this post in threaded view
|

Re: is there a standard way to get the g-b-s to apply multiple patches?

Eric Blake (cygwin)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Yitzchak Scott-Thoennes on 1/11/2006 5:00 AM:
> I'm working on updating the fortune package and switching to use the
> generic build script, but I'd like to have the source package to have
> the original source, the current debian patches, and a separate patch
> file with my patches.  The debian package maintainer is also the
> maintainer of the upstream source, but he isn't updating that, just
> letting the debian patches get bigger and bigger over time.  I'd like
> my patches to be distinguishable from what's standard.

Take a look at bash and readline, where I distinguish between Chet Ramey's
official upstream patches vs. my cygwin-specific patches; the
bash-3.0-14.patch contains only my differences after the upstream patches
have been applied.  In particular, my modifications to g-b-s for bash
3.0-14 or readline 5.1-1 try to be pretty generic about bundling the
upstream patches.  If you find it useful, or have any improvements, then I
can consider making the patch robust enough to propose for g-b-s itself.

- --
Life is short - so eat dessert first!

Eric Blake             [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDxQ2684KuGfSFAYARAmQ+AJ0dzgG9Vc4hNUdgKc6A5/wjgKKBUgCgqBOJ
vEpC2DVwcA6z7YL0wZe27eg=
=usDK
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: is there a standard way to get the g-b-s to apply multiple patches?

Brian Dessent
Eric Blake wrote:

> Take a look at bash and readline, where I distinguish between Chet Ramey's
> official upstream patches vs. my cygwin-specific patches; the
> bash-3.0-14.patch contains only my differences after the upstream patches
> have been applied.  In particular, my modifications to g-b-s for bash
> 3.0-14 or readline 5.1-1 try to be pretty generic about bundling the
> upstream patches.  If you find it useful, or have any improvements, then I
> can consider making the patch robust enough to propose for g-b-s itself.

I noticed that.  However, there is one gotcha with this method.  Because
the outermost -src tarball contains files that unpack into the upstream
source dir, this can cause confusion if you want to start over.
Example:

$ ./foo-1.0-1.sh prep conf build
# decide that for some reason you want to start over
$ rm -rf foo-1.0/
$ ./foo-1.0-1.sh prep conf build

However, the second build will not contain the Cygwin specific patches,
only the upstream patches.  This is because they were deleted at the
"rm" step.  To start over you have to re-unpack the toplevel -src
package, because it contains things that live under foo-1.0/.

Brian

Reply | Threaded
Open this post in threaded view
|

Re: is there a standard way to get the g-b-s to apply multiple patches?

Eric Blake (cygwin)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 1/11/2006 7:03 AM:

> Example:
>
> $ ./foo-1.0-1.sh prep conf build
> # decide that for some reason you want to start over
> $ rm -rf foo-1.0/
> $ ./foo-1.0-1.sh prep conf build
>
> However, the second build will not contain the Cygwin specific patches,
> only the upstream patches.  This is because they were deleted at the
> "rm" step.  To start over you have to re-unpack the toplevel -src
> package, because it contains things that live under foo-1.0/.

Eek, you're right.  I'll have to modify my procedure to create
foo-1.0.upstreampatches.tar.gz2 (or some such name), rather than sticking
the patches in foo-1.0/.  Hopefully I will get it working as part of my
efforts to prepare a bash-3.0-15 in the next week or two.

- --
Life is short - so eat dessert first!

Eric Blake             [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDxRIx84KuGfSFAYARAv0SAJ9Yb7L18ZpthHdlrt6NtvXuhOlVQACfSvr3
D/4adUgolB8th3Kt7hxy0fk=
=WvcD
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: is there a standard way to get the g-b-s to apply multiple patches?

Igor Peshansky
On Wed, 11 Jan 2006, Eric Blake wrote:

> According to Brian Dessent on 1/11/2006 7:03 AM:
> > Example:
> >
> > $ ./foo-1.0-1.sh prep conf build
> > # decide that for some reason you want to start over
> > $ rm -rf foo-1.0/
> > $ ./foo-1.0-1.sh prep conf build
> >
> > However, the second build will not contain the Cygwin specific patches,
> > only the upstream patches.  This is because they were deleted at the
> > "rm" step.  To start over you have to re-unpack the toplevel -src
> > package, because it contains things that live under foo-1.0/.
>
> Eek, you're right.  I'll have to modify my procedure to create
> foo-1.0.upstreampatches.tar.gz2 (or some such name), rather than sticking
> the patches in foo-1.0/.  Hopefully I will get it working as part of my
> efforts to prepare a bash-3.0-15 in the next week or two.

Apologies for not having the time to think this through right now, but may
I suggest that there always be exactly one patchfile -- either a real
patch, or a (compressed) tarball?  Then the patch step could detect which
one it is and either apply it directly, or unpack the tarball and then
apply the patches it finds in it.  FWIW, the patches in the tarball could
unpack directly into PKG-VER/CYGWIN-PATCHES.  Does this sound ok?
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"