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

[James Rowe]

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

pgp9QN3lzqPx3.pgp
Description: PGP signature