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

[Martin Quinson]

Sorry, I'm going to do a short answer to a long mail ;)

If I understood well, you're maintaining a parallel version of quilt to allow
extra stuff to be placed in external packages. 
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.

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?

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 ?

I'm more confident in scripting than in english discussions ;)

Thanks for your time and patience, Mt.

On Thu, Feb 13, 2003 at 06:10:31AM +0000, James Rowe wrote:
> On Tue, 11 Feb 2003 18:31:38 +0100
> Martin Quinson <address@hidden> wrote:
> 
> > Well, well, well.
> > 
> > I did not guess that my mail will deserve such flames.
> 
>   I'm sorry you felt that was a flame, it wasn't the intention at all.
> 
> > Do you mean that we should release right now, since you need some
> > features only present in the CVS?
> 
>   To be honest, the release thing is of little consequence.  We
> have CVS-based solution in place here, and that suits us for now.  I'm
> going to be trying to move OB's over to quilt too(atleast for
> import/export), as it now has support for our current authorisation
> method, and whether a numbered release is about matters very little.
> 
> I've been tempted to move with a release from here in a few weeks, once
> we have ironed out some problems.  It is going to depend on how much
> needs to be redone from CVS to get a working system.  And to a lesser
> degree it depends on me getting permission to re-license some of the
> supplementary work which has been taken from the old system.
> 
>   As far as features from CVS, we don't have any artificial restrictions
> on source type so it doesn't cause a problem.  If you want to
> install/build packages from CVS, you can(if a recognised server exists
> in the ebuild-a-like anyway).
> 
> > What is the relation between the need of tests and completion module
> > and automake. Please don't tell me that you plan to use autotest...
> > From the info file:
> >      *Note: This section describes an experimental feature which will
> >      be part of Autoconf in a forthcoming release.  Although we
> >      believe Autotest is stabilizing, this documentation describes an
> >      interface which might change in the future: do not depend upon
> >      Autotest without subscribing to the Autoconf mailing lists.*
> > I don't think so, since, autotest is part of autoconf, not automake.
> 
>   The completion stuff, along with docs, have been split in to a
> supplement package now anyway. Mainly because they no longer really
> apply at all to a copy of quilt from savannah.
> 
>   Tests were, for a start, basic distribution tar ball tests, the same
> ones that have helped us to kill the need for the rolling-build for
> every minute project.
> 
>   Back in the old days<clouding over>, we used to have an immense
> library of makefile includes to help us deal with things like people
> thinking '-p' is a standard option to mkdir or install can just be given
> 500 in-files.  Now 9 times out of 10 these and the insanely large number
> of other "niche" system effects don't even need to be addressed because
> the good people involved with automake have already done so(and those
> methods have received much more testing).   I suppose I could add out of
> tree builds to that list too, but it is covered by tar ball testing.
> 
>   I can imagine the response 'oh those are an easy fix.'  Yeah, and
> the same is no doubt true of the next one, and the next one and the one
> after that...
> 
>   I guess if we were to restrict people to static packaging formats
> and enforcing all manner of tool requirements some of these problems
> wouldn't occur, but it is something that is not going to happen aslong
> as there is a viable alternative.
> 
> [  As for 'mkdir -p' remember CVS quilt has scripts which use 'mkdir
> -p'.  So depending on your opinion this either makes it twice as bad or
> not a problem.  It isn't like all of these things are even
> non-linux, right now I know there are even linux users who can't take
> advantage of quilt because of this and mktemp.]
> 
> [  Yeah, I am mixing reasonings now.  Because they should be mixed, this
> is about portability and not just makefiles after all.  But you need to
> start somewhere.]
> 
> > My point was that in my opinion, quilt was small enough to rely on
> > autoconf only, and not on the whole auto* familly. I may perfectly be
> > wrong. I did not test it on other platforms lastly. If it is the case,
> > please don't flame me. Show me what points of the current solution are
> > problematic, and how automake could solve them.
> > Anyway, since I didn't provide much work for quilt until now, I don't
> > feel that my opinion is definitive in any way. 
> > I give my point of view, but Andreas is the one you have to convince
> 
>   And my opinion is that I can't be bothered to waste anymore of time
> discussing this.  I can see things aren't going to change, so I can't be
> bothered.
> 
>   As I almost said at the top of the mail, I've split the standard quilt
> stuff from ours.  Hopefully that should mean that as we work through the
> current problems I can send fixes for things that affect standard quilt
> back here.  Or it could go the other way, and things could get replaced
> altogether here. This has unfortunately already had to happen with
> backup-files, and seems to be happening with a few of the other commands
> too(like diff).
> 
>   I'm still of the opinion it makes more sense to be working on a single
> quilt, with a small additional package as I wouldn't expect or want to
> push for example package specifics.  This is the only reason I've
> rewrote big sections of our modules over and over, even when it has
> meant having to re-fix the same problems that we have already got over.
> 
>   From the outset I've had differing opinions about direction, and most
> of them are non-negotiable.  I have to support myself and the people
> that use quilt here first and foremost.
> 
>   Although somethings like global quilt data I can move on, others
> aren't.  Personally I can grudgingly cope with the likes of .pc in the
> source tree, but I know how hard it has been to convince others that the
> pollution is okay.  The package split is my way of deciding that I can't
> continue to compromise on some of the problems, and also that there is
> no one to compromise with on others.
> 
> Jay
> 
> -- 
> 
> www.jnrowe.uklinux.net
> GnuPG key fingerprint = 7721 D12B 822B 20FE FCE6  B2B7 7CDF C9DF D16A
> 87D7



> _______________________________________________
> Quilt-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/quilt-dev


-- 
Each language has its purpose, however humble.  Each language expresses the
Yin and Yang of software.  Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
          -- The Tao of programming