On Mon, 31 May 2004, Norman Gray wrote:

> Tim,
>
> On 2004 May 31, , at 01.03, Tim Jenness wrote:
>
> > Pre-empting the discussion, I don't think it's an issue since most
> > things
> > can migrate from the current installation locations to a new
> > "standardised" location without affecting other things. This is easy
> > once
> > everything works in CVS. [although we did agree that we should not be
> > installing shared libraries into share]
>
> True enough.  I think we should still have a brief chat about this, to
> confirm it really is as straightforward as that, but no more than that.
>   See below.
>
> >> Anything else?  Is that a reasonable division?
> >
> > The install target needs to install versioning information somewhere so
> > that the starversion command will continue to work. Currently
> > starversion
> > mainly looks in the datestamp files but there is no equivalent at the
> > moment.
>
> The manifest file which is installed by the `install-manifest' target
> currently includes a <version> element which contains the version
> declared in the configure.ac.  Is that sufficient?

I think so.

> DavidG: how's about this for the CVS part of the programmers' meeting
> agenda?
>
> 1. Brief summary of status [Norman, 5m]
>
> 2. Arrangements for the CVS-week [Norman, 5m]
>
> 3. Outstanding CVS issues.  See message
> <http://www.jiscmail.ac.uk/cgi-bin/webadmin?
> A2=ind0404&L=stardev&T=0&F=&S=&P=245>.  Some of these issues (6: yes,
> 8: standing action?, 13: fixed?) have already been resolved, and the
> thread after that contained some opinions.  Issue 4 probably doesn't
> have to be decided now, since, as Tim points out, such a change can be
> made centrally later.

Actually, issue 4 specifically was one decision I think we should make
beforehand. Continuing to install shared libraries into /share is a
mistake that should not be repeated. Other things (such as whether to put
ifl files into bin/app or into share/app etc) can be deferred.

> 4. Packaging of components for separate distribution.  What should we
> aim for?  When should we do it?  If the answer is `Debian + RPM
> packages, during the CVS-week' then that's easy.  Or do we just do it
> when we next get the chance?  There's probably no need for any
> technical discussion, just the decision about what packaging goals
> should be on the CVS-week agenda. [10m??]


Can the RPM .spec file be built using information in the MAkefile.am and
configure.ac?

> ...and this for the `agenda' for the CVS-week (partly from the `CVS
> discussion topics' message of last week):
>
>    1. CVS issues: 9: AST/Fortran link queries
>    2. Uninstaller tool necessary (issue 10)?
>    3. Testing (issues 11 & 12): should regression tests run before or
> after installation?; do we need a separate installation test?
>    4. Do we need separate `install' and `install-manifest' targets.
>    5. Building documentation by default?  When?
>    6. Distribution and packaging: technical issues not resolved at the
> programmers' meeting.
>    7. What `codeline ownership' features are desirable?
>    8. [DLG's message:] Aim: get everything into CVS and set up new build
> system ( checkout, configure, make) - working on various flavours of
> Unix plus MacOS-X (and Cygwin/Windows if possible in the time
> available). Note that the "essential" apps must build and work but
> other low priority apps may fall by the wayside at this stage -
> although even for these the code will be in the CVS repository.
>
> That's turning into quite a lot of discussion at the CVS-week, rather
> than the coding frenzy anticipated.  Is this inevitable, or has this
> division of policy vs. coding got out of hand?  There seems to be a
> danger that the CVS-week could turn into an extension of the
> programmers' meeting, which is undesirable.
>

It does worry me. If we spent more than a couple of hours discussing
things rather than actually editing code then I think we would be on the
wrong tack. Many of the above issues can be deferred until after software
is in CVS. I think the primary goal of the week should be to have a system
where all the code is in cvs and builds and installs. Issues such as 2,
5,6 and 7 are not relevant for that. 4 is "trivial" since we need the
manifest for starversion to work and for any proposed uninstaller to stand
a chance (although the uninstaller could be ignored if we use RPM etc -
why require a special uninstaller if we can get the native package
systems to do it for us).

--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj