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
