Am Sonntag, 09.11.03 um 15:31 Uhr schrieb Michael G Schwern:
On Sun, Nov 09, 2003 at 01:32:10PM +0100, Max Horn wrote:Note quite. Because the dpkg installed in /sw has its status/config files in /sw. Getting it to work and live in our fake /sw is not that trivial. It might be possible to achieve that with a chroot box, though.<snip>Sorry to have not been clear, I intend to build up a dummy fink installation for testing purposes.Of course this way you can only test a small fraction of Fink. E.g. the
whole bootstrap isn't covered by this (which includes compiling stuff
like dpkg and apt). Also, you can't test building & installing packages
this way (i.e. without source modifications to fink), because fink
needs root & dpkg for this, something which requires a) interactivity,
and b) dpkg/apt/etc. in the Fink installation, which wouldn't be there.
The latter problem maybe can be worked around by symlinks from
/sw/bin/dpkg to /my/fake/sw/bin/dpkg etc. Dunno if that would work.
That's ok. The tests that need dpkg can be optionally dependent on it. If
the user has the dpkg and apt packages already installed they'll be used.
We're just testing fink, not dpkg. You've got to draw the line somewhere.
There's no problem for the tests to rely on fink packages being already installed. The only thing you don't want is it to alter /sw.
I've done this sort of thing before (look at ExtUtils::MakeMaker).
That's, IMHO, comparing Apples and Bananas. Sure, I have done stuff like this before, too . But installing ExtUtils::MakeMaker is, in my estimation (please correct me if I am wrong) much less complex than install Fink and fink.
fink's about half the size. Only has one platform to deal with. They're
both large sets of crufty code. They're both package build systems.
They both build themselves.
I don't argue that ExtUtils::MakeMaker is complex - I was specifically referring to *installing* it. :-). The "fink" tool is only a part of "Fink". As such it relies on several other components (dpkg, tar, apt, ncurses, ...) which have to be installed along with it. That takes time, and makes "faking" the environment harder.
After that, it's very well possible ExtUtils::MakeMaker is as complex or even more complex, but that's not relevant :-)
MakeMaker contains several dummy Perl modules for testing. It goes through
the process of running the Makefile.PL and make and checking that all the
output is correct and the module gets built and installed into a temp
location. In addition it tests the methods individually as best it can.
Its all basically the same technique except for this bootstrap bit which
I wouldn't worry about how we're going to test it just yet.
I am not worried about testing the bootstrap. The thing is, what I still don't quite see is how to do testing *without* a fully bootstrapped test environment. I.e. how to fake one in a useful manner.
[...]
You've only just got the first 1% tested and already you're worrying aboutActually, I would be quite content already if we just had tests for all the modules. But going beyond module testing for me seems more like the "second 50%" and not the "last 1%"...
the last 1%. Relax. Have some dip.
[...]
Interesting, I didn't even know we have a "fink purge" ? Somebody must have sneaked it in :-)Not that this is a good example, because it's trivial to restore the fink database ;-)
And the broken "fink purge" that just accidentally deleted every package? :)
Anyway, sounds like yet another misunderstanding, a problem of terminology: what do *you* call the "fink database"? For *me* it is the Storable drive "database" containing all the package descriptions, which is in turn derived from the .info files and thus trivial to restore.
[...]
Let's shelve this. There's a whole lot more basic testing ground to be
covered before we get to this point at which point I'll hopefully have a
better gesalt for fink and you for testing.
Just to clarify this: I think I have a pretty good grasp of testing. I have done test driven development a lot myself in the past. I even made other people use tests :-).
I wouldn't start with the things I explained in my mails (in case you thought that was what I proposed). I simply replied to your statements, trying to explain the situation, and thus trying to increase your understanding of how the fink build system and installation works. Sorry if that failed due to miscommunication :-/
Cheers,
Max
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
