Re: Readying CHANGES file in preparation for release.

[Brian Dessent <brian at dessent dot net>]

Max Bowsher wrote:

> I think the setup that we currently have is undeniably better than the
> current release version, so I am thinking of putting out a beta and
> announcing it to the main cygwin list, to get some final testing before a
> real release.
> 
> Are there any things that we should wait for before doing a beta?

Sorry for the delay.

I think it would good to do an official test release and announce it on
the main list.  I haven't yet looked at Igor's patch but I think it's a
great idea and we should perhaps add that first.

There are still some minor issues that need addressing before doing an
actual (non-test) release, though.  Hopefully with more testers we can
get a good idea of what still needs tweaking.

One thing that I have been meaning to look at soon is re-doing the
install procedure to properly address the dependency issue.  I would
like to treat each of the possible 4 steps (preremove, delete files,
install new files, postinstall) equally and do them all in the correct
order, instead of trying to do them as seperate operations.  The general
idea I had in mind for the logic is to make one large list of all such
necessary operations, and then sort it based on the requirements for
each step.

However before addressing this we need to discuss the idea of whether we
want to go down the road of having an "install-requires" that would be
seperate from the normal "requires" line.  This would simplify the logic
of the above, because it would let us express that a certain package
depends on only e.g. "cygwin, ash, libfoo" for its
postinstall/preremove, rather than having one single list of dependent
packages, most of which are probably only runtime requirements.

Regardless of how we implement it, setup would have to fall back on
using the current "requires" line for all ordering decisions because
it's unrealistic to think that we'd be able to convert all the existing
setup.hints at once.  So in that respect it's not crutial to make a
decision now, as setup would have to cope with the current situation
regardless.

I'd really just like to see what people think about the idea, which has
been brought up before.  If it turns out that it's just too much work
for maintainers then we can skip it.  However, if we decide to continue
as-is then I think we'll have to modify the current "requires" lines on
certain key packages to eliminate a lot of the loops that exist as it
is.

On a somewhat unrelated note, a while ago I was playing around with the
script that I'd wrote that converts setup.ini into a directed graph in
the 'dot' language for input to GraphViz.  One of the GraphViz utilities
will do a 'transitive reduction' on a graph.  This means that if you
have A -> B -> C (where in this context A -> B means 'A requires B')
then you can eliminate the edge A -> C if it exists.  The setup.ini
graph contains approximately 500 nodes and 1800 edges, and after running
the transitive reduction it contains only ~900 edges.  This means that
roughly half of all packages specified in 'requires' lines are redundant
information.  Not that I'm advocating that maintainers should somehow be
responsible for knowing or finding these redundancies (since a lot of
them are probably non-obvious) but I did find it interesting that there
were that many transitive edges.

Brian