Am Sonntag, 09.11.03 um 06:15 Uhr schrieb Michael G Schwern:
On Sun, Nov 09, 2003 at 03:30:31AM +0100, Max Horn wrote:AFAIK this is simply the ability to generate fink from fink.in and the
like
without installing it
Well fink needs a working Fink installation. It is possible to do some
hacking and get it to work in a partial pseudo installation (we do this
for the package database, which is driven by fink on a Linux server),
but that only allows access to a fraction of fink's capabilities.
I am not sure how (if?) you suggest we could run fink w/o having a Fink
installation around. Personally I see no point in it, either. Anybody
who wants to develop or test fink will have fink installed.
Sorry to have not been clear, I intend to build up a dummy fink installation
for testing purposes. Because fink is already fully relocatable (ie. /sw isn't
hard wired) this should be pretty straightforward. It'll probably consist
of a config file (which is already there in t/basepath/etc/fink.conf) and a
small dist tree containing whatever we need to test things. No point
laying it all out upfront, it'll build up with whatever is needed at the
time.
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.
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.
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 :-).
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 ;-)
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.
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.
So, in essense, seperating the build and install phases and making it automatable.
You mean more automatic than "./inject.pl" ? Telepathy controlled maybe? 8-). Seriously, would you please explain what that would mean?
I'm just a bit confused. I forgot inject.pl can be run independently of
bootstrap.pl. inject.pl should work.
Besides this, as I explained, if you look at fink.info.in, then you see that setup.sh is essentially the "build" and install.sh the "install phases you talk about. What you want, essentially, is not (to my understanding) a separation of build/install (there isn't much to separate anyway, both are trivial). Rather you want a "setup test environment" phase. *That* is something I can understand and could work forward to.
Not really. There are simply two meanings to "install" in this context, which might be cause of our problems understanding each other :-)
Like I said, I'm the wrong person to be normalizing the build process as
I don't really know anything about it. I just know what the end result
has to be for it to be testable.
But note that to be able to actually use fink as a whole, it has to be installed into a working "Fink" installation, i.e. with all its environment setup. You'd have to do some hacking to be able to use it w/o installing it.
Hmm, circular build dependencies.
(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).
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
