This is the mail archive of the
mailing list for the Cygwin project.
Re: gbs patches?
Igor Pechtchanski schrieb:
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.
yes, upstream is you :)
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.
no, difforig changed a lot since the last time.
I'll resubmit splitted.
new args: requires difforig up setup
* reconf is currently invasive. most of the time autoreconf is easier.
I added a fixup function which can easily replace the current reconf
* 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.
creates the single requires: line for setup.hint
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
* up (optional)
if rsync_up_target is defined rsync the package files to
the distribution server.
* 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,
Ok, I'll split. Justed wanted to know.
having them in the source commented is also my preferred style, but
since current gbs is quite comment-clean I just wanted to know.
I'll have some time next week to look at all the patches, so please keep
charles also has some useful helpers for splitting libs
into base and devel, which might be good to have (commented at least).
I'll fix up() to fit into the splitted package template also.