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

[Andreas Gruenbacher]

On Thursday 13 February 2003 07:10, 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

-- 
------------------------------------------------------------------
 Andreas Gruenbacher                                SuSE Linux AG
 mailto:address@hidden                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany