gbs patches?

Igor Pechtchanski pechtcha@cs.nyu.edu
Mon Oct 11 00:20:00 GMT 2004


On Sun, 10 Oct 2004, Reini Urban wrote:

> Aren't there any more gbs patches accepted?

Sorry, Reini, I've seen your difforig patch, but was very busy at the time
you submitted it, and quite frankly forgot about it afterwards (I'll look
in the archives and re-familiarize myself with the discussion and the
issues).  ISTR that I was reluctant to include a functionality that the
users will not need, but I've already accepted maintainer-only
functionality patches, so if that was my only objection to your patch,
I'll check it in tomorrow.

> I've got a lot of new functionality.
> Maybe someone upstream may find it useful.

"upstream"?

In any case, I've glanced at your new patch (which is reversed, BTW), and
some of the parts are obviously useful (e.g., expanding install_docs
patterns, removing source in prep(), etc), and others require some
discussion.  It would be nice to get them as separate simple patches, with
respective ChangeLogs.  BTW, unless the difforig functionality changed
since your last patch, you don't need to resubmit it.

> new args: requires difforig up setup
>
> issues:
> * reconf is currently invasive. most of the time autoreconf is easier.
>   I added a fixup function which can easily replace the current reconf
>
> changes:
> * catch interim log files and put them as -log.tar.bz2
>   into the src package.
> * added binary package sig.
> * depend sorted
> * new files for the docs list.
> * make test changed to make check.
>
> new features:
> * requires
>   creates the single requires: line for setup.hint
> * setup
>   poor mans setup.
>   missing: preremove, permissions, check if in use.
> * difforig (optional)
>   create a smaller interim patch from .orig files.
>   This eases development (and is standard on postgresql).
>   Most of the time (if autoreconf is not involved) 1:1
>   the same as current mkpatch, which is quite invasive.
>   Better than my version from
>   http://sources.redhat.com/ml/cygwin-apps/2004-09/msg00044.html
> * up (optional)
>   if rsync_up_target is defined rsync the package files to
>   the distribution server.
>
> future:
> * make splitting seperate base, -devel packaging easier.
>
> How to put all this into ChangeLog format? Should I?

The "issues" and "future" parts above don't, IMO, belong in the ChangeLog.
The rest is rather obviously translated into simple ChangeLog entries --
see the CVS ChangeLog for examples.  I would put most of the description
of functionality into comments in the source instead of the ChangeLogs,
though.

I'll have some time next week to look at all the patches, so please keep
them coming.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw



More information about the Cygwin-apps mailing list