quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Quilt-dev] auto~conf/make


From: James Rowe
Subject: Re: [Quilt-dev] auto~conf/make
Date: Fri, 14 Feb 2003 07:54:43 +0000

On Thu, 13 Feb 2003 09:46:18 +0100
Martin Quinson <address@hidden> wrote:


> If I understood well, you're maintaining a parallel version of quilt
> to allow extra stuff to be placed in external packages. 

  Yeah, but if I was to say that I alone am maintaining it I expect
Chris and Rach would get mad ;)

> So, what changes do you need to quilt so that you can use the CVS
> version with no modification ? I guess you have patches already
> available for that somewhere. Could we see them? Or even better, could
> you commit them? We could tag and release the current CVS, and start
> for another round of developpement, consisting in integrating your
> ideas.

  I can't honestly imagine a time when savannah quilt will meet all
our needs.  Short of having a massive conditional install the added
bloat would be a hindrance to many other people(I know I remember a
"bug" report about RPM tools).  I don't see this as a problem anyway,
because some features are intrinsically site specific.

  As far as patches are concerned after the last round here I decided to
split the packages, and save all of us time so yes and no.  Yes there
are patches, no they are not in a state were they could be merged
right now.

  Plus I have been driving others to rewrite the whole section when they
have found minor problems in the savannah quilt to save us time down
the road.  This happened just yesterday with parse-patch, after the
final person became annoyed with '%header' in distributed patches and
added a package template for patch generation(goes in
$QROOT/$package/$package.tmpl on here).

  Then there is the rewrite of backup-files, or in this case removal. 
It was rewritten because it would be quicker than fixing it, and the
rewrite is as bash loadable.

  Like I had said in the previous mail, I am awaiting on some licensing
answers from my boss.  As quilt has been moving too slowly we decided to
use previous work in the supplementary package.  Some of which is
unlicensed, and some of which is owned by my company.  Relicensing is
not normally a problem once there has been a request anyway(even
if it means rewriting the ICE module, because I am sure that one was for
made for a client initially).

  And some of it should be as simple as a sed command to strip the
gettext '$'s from echo commands.

> Could we imagine that the external packages you did develop can land
> in the same CVS than quilt ? Afterall, you've a write acces to the
> CVS, also, so you could put your extra developpements there, couldn't
> you?

  Well, we'll see what happens after I post the start and breakdown
here I suppose.  I still expect there to be a big dismissal.

  I can't even imagine an ordering now, as a lot has become
cross-dependant.  Hence the reason I expect the dismissal, too intrusive
and definitely breaking those RPM things.  Initially I have no plan of
reimplementing sections anyway, until some degree of acceptance has been
shown(see next comment).

> To say it another way, you kind of convinced me of the useness of
> automake, and even more, of the use of autoconf to change not only the
> first line of every script to point to the right location of bash, but
> also to choose the right implementation of every feature (like mkdir)
> in the body of scripts themselves. So, instead of discussing over and
> over what should be done, why don't we begin to implement (or
> integrate) that ?

  Truthfully? because it has become a massive waste of my time.  I could
spend the rest of the weekend preparing and splitting the whole in to
bitesize chunks for posting and then have them sweep rejected.  But as I
am going to be sitting on a plane trying to get home all afternoon I
probably will do a quite a bit(you can't play UT with a mobile phone
connection).

Jay

Attachment: pgpZ0m8BgnErK.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]