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

[Andreas Gruenbacher]

On Friday 14 February 2003 08:54, James Rowe wrote:
> 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.

I believe we should try to keep the quilt core free of exotic stuff, and 
rather put such things in add-on packages. But since I'm mostly 
interested in getting the core improved right now, I just won't spend 
time on an add-on mechanism.

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

Sorry, but you are (again) too unspecific. What was the exact problem? 
What did you do about it? And bloody why don't you share the solution?

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

Show us the solution.

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

Quilt moving too slowly is mainly your own fault. You have sent one big 
configure.in patch, which has caused me considerable afterwork. Then 
you have sent another big Autoconf patch, which I just haven't found 
the time to break down into pieces. So unless you deliver more easily 
digestible pieces, there's really no point in complaining about lack of 
progress.

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

Well, I'm able to fix things for RPM, for example. Breaking things 
intermittently is unavoidable. There is nothing wrong about that.

> Initially I have
> no plan of reimplementing sections anyway, until some degree of
> acceptance has been shown(see next comment).

Are you talking about these %sections in patches? Then just don't use 
them. Quilt will not generate them (unless you are working with a 
really old snapshot).

> > 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
> into bitesize chunks for posting and then have them sweep rejected.

There has been a single, huge patch that hasn't been integrated yet, 
because it does many things at a time. You seem to be expecting Martin 
or me to do all the integration and cleanup work after you, but I don't 
think that will happen.

--Andreas.