This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

ok. 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.

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
* 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, though.

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
them coming.

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. -- Reini Urban

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]