gbs patches?

[Reini Urban]

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.
> 
> "upstream"?

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

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
http://xarch.tu-graz.ac.at/home/rurban/