Good - I felt I wasn't expressing what I wanted. First, I should say that I don't have the expertise (yet) in Linux that I have in other platforms. So I may still have some misconceptions. I expect this to change within the next few months. I'm getting a new system to dedicate to developing NUnit on Linux, rather using Windows and only running tests on virtual machines. But for now, my ideas are limited by my experience.
ANYWAY... it seems reasonable for me to have a private copy of NUnit hidden in /usr/lib/mono for internal use. The natural place to install an NUnit application would seem to be /usr/lib/nunit or (if we support multiple concurrent versions) /usr/lib/nunit-x.x. The problem comes with commands, which are all in the /usr/bin directory and have play well together. This can be equally true on Windows, except that Windows developers seem less likely to use the command shell. It is used in nightly build scripts, but in that case an awkward syntax is not a problem. Anyway, most Windows teams don't actually "install" nunit, but copy it to their development tree. One approach is to use command scripts like nunit-x.x for each version of NUnit installed, with a master script that points to the latest. That's how I do it on my own (Windows) systems. For Linux, I think it would be preferable for the nunit script to reference a conf file. The last installed nunit package could update the current version and subordinate scripts might not even be necessary. One reason normal users need to have side by side installs of different NUnit versions is that they need to try out all their existing tests on the new version before committing to it. In fact, this is a weakness in NUnit and - even more - in the management of packaging in Windows itself. It could be that this will become very simple once we have packages that install and revert easily. That's what I'm hoping anyway. If a user did not need to change any build scripts to go to a new version of NUnit, then it would be only developers of NUnit who need to worry about multiple installs and that can be dealt with using different roots. I'm looking for folks who will help with making this work smoothly and seamlessly, btw. :-) Charlie > -----Original Message----- > From: Atsushi Eno [mailto:[EMAIL PROTECTED] > Sent: Friday, November 28, 2008 1:39 AM > To: Charlie Poole > Cc: [email protected] > Subject: Re: [Mono-list] SPAM-LOW: Re: NUnit Version - Upgrade soon? > > Hi Charlie, > > Ahh, I get your point, that is a visible problem. Since I'm > just a volunteer to upgrade the version here, I am not at the > position to decide what we should include in our package. > nunit-console shell script is not actually used to build mono > and mcs (instead we use mono-wrapper and nunit-console.exe > directly) and this script can be removed if we just think > about mono and mcs. > When it comes to other modules, for example we use > nunit-console directly in Olive. So I assume we still sort of > need a shell script. > > I assume we could rename nunit-console to mono-nunit-console > or whatever, to explicitly indicate that it is for mono internals. > > Is this the only concern, or is it just an example? :) > > Atsushi Eno > > > Charlie Poole wrote: > > Hi Atsushi, > > > >>> If you want to attract folks to Mono, then I think it's > >> important not > >>> to confuse them. :-) > >> If there's reasonable reason people get confused because of my > >> interpretation or effort on upgrading nunit version, then I feel > >> sorry ;) > > > > Even though this thread started as a result of your > upgrade, I don't > > think the upgrade causes the confusion. I think it already > existed for > > people who are moving from the Windows world to Linux+Mono and your > > upgrade just continues in the same way it has always been. > > > > Specifically, if I type "nunit-console" I get the version > you install > > with NUnit. I can't change that without over-writing a file that is > > part of mono. But installs should not overwrite files > created by other > > packages, so I have to create a comand like "nunit-console-25" > > and the old version remains the default when it makes more > sense for > > the new version to be the default. Of course, an individual > user can > > choose to rename these files and deal with package problems > manually, > > but my install can't (shouldn't) make such a decision. > > > > Can you see the problem? > > > > Charlie > > > >> Atsushi Eno > >> > > > > > > > > _______________________________________________ > > Mono-list maillist - [email protected] > > http://lists.ximian.com/mailman/listinfo/mono-list > > > > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
