On Sun, Nov 09, 2003 at 01:32:10PM +0100, Max Horn wrote:
> >Sorry to have not been clear, I intend to build up a dummy fink
> >installation for testing purposes.
<snip>
> 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.
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.
> >The ideal process is edit, build, test, install. In order to do this
> >you
> >need some sort of testing data.
>
> Understood. But I find it hard to fit this schema on fink, because we
> have two different kinds of install. Two different kinds of build. What
> do you want to test, a full "Fink" installation (the whole distro,
> meaning a bootstrap), or just installing "fink" (the package manager)?
>
> I assumed so far that you meant the latter, but I am not sure anymore
> :-).
Dunno yet, I've just gotten started. Like I said, a lot of this will be
handled as necessary. No point drawing up a big plan now when I hardly
understand how fink works. I can't address testing bootstrap because I've
never really bothered to look at it. Right now I'm just trying to figure
out where to go from Fink::Config and Fink::Base!
You've only just got the first 1% tested and already you're worrying about
the last 1%. Relax. Have some dip.
> > A dummy install. Some static data you can
> >beat on and don't care about mangling if you make a mistake. Edit,
> >build,
> >install, test means you have to install your untested code and *then*
> >test
> >it against your live fink installation. This means you find out that
> >your
> >patch wrecks the fink database *after* its already done so to your
> >running
> >fink.
>
> 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? :)
> A much nicer example is testing "fink cleanup", which removes unused
> .debs. Testing that thoroughly would be a very nice thing. There are
> still some quirks left with it. Writing some good tests should help a
> lot towards finding and fixing those problems (and keeping them fixed).
>
> For this to work, one would indeed need some kind of dummy
> installation, in which one could put a dummy package set. Then create
> dummy .deb files ("touch" should sufficient). Then run "fink cleanup"
> and check if the correct .deb files/symlinks were deleted.
Yep, something like that. Don't get ahead of yourself. :)
> For other things, we'd have a well designed dummy package set which
> would cover many situations: package foo only in stable, only in
> unstable, in both; newer in stable,newer in unstable, same versions;
> etc.. Then test the output of fink list / fink desc etc.
Yep, those are the sorts of permutations you'll have to cover. With
situations like that where the possiblities are near endless its best
to test as the bugs appear rather than drive yourself crazy trying to
do a complete coverage.
> Not really. There are simply two meanings to "install" in this context,
> which might be cause of our problems understanding each other :-)
>
> (1) Bootstrap
> -> create a brand new Fink installation with a new config file, fink
> executable, the essential packages compiled etc.
> (2) Inject
> -> inject a new package manager ("fink")
>
> (1) Is something much complex than (2), and also takes a rather long
> time because dpkg etc. have to be compiled. (2) OTOH is very simple.
> For comparison, (1) takes hours on my G4/400, (2) takes something like
> 70 seconds (of which 40-50 are spent rebuilding the package database).
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.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Shrtr is btr.
-- Abhijit Menon-Sen in <[EMAIL PROTECTED]>
-------------------------------------------------------
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
