Hi,

The bootstrap compiler and the .info files for fink installation are ready. Can someone please upload them?
http://michael-ep3.physik.uni-halle.de/fpc-2.0.4.powerpc- darwin.bootstrap.tar.bz2

should go to:

fpc/beta/2.0.4-rc2/source/

http://michael-ep3.physik.uni-halle.de/fpc.info

and

http://michael-ep3.physik.uni-halle.de/fpc-doc.info

I think the .info files should go to fpcbuild/tags/release_2_0_4_rc2/ install/macosx

Done.

Tomas, can you this since you are doing all the RC tagging?

Jonas

Jonas Maebe wrote

On 20 Jul 2006, at 15:18, Schindler Karl-Michael wrote:

.
.

Right. This is little bit chicken and egg
problem, isn't it? If I understand it correctly,
you need to have the complete exported sources
zipped before you can create these files
(otherwise the MD5 checksum cannot be created).
However, you want to add that file to the tree
afterwards. Once you do it, nobody can re-create
your zipped file from the tree again, because the
checksum changes and thus the file (or the
included checksum at least) becomes invalid...
Correct me if I understand it wrongly.

If my assumptions above regarding how it works
are correct, my suggestion would be:

1) Add current files to trunk and merge to fixes.

2) As part of preparation for the next round
(depending on whether that becomes RC3 or the
final version - I currently expect the former),
the files in SVN get updated with new directories
and filenames (I'd add this to the release
template to make sure this step isn't skipped).
The checksum is _not_ updated at that stage (it
isn't known anyway).

3) The files get tagged and exported as before
(let me know whether you prefer .tar.gz or .zip
sources in future builds - we can have both if
needed).

4) If needed, the files might get updated with
new checksums and committed to SVN (but not to
the release branch - only trunk and fixes) by
somebody.

Note: Committing of the updated version to SVN in
the last step probably isn't strictly necessary
(possibly not even useful). Instead of doing
that, you might supply a script for update of the
checksums instead (and include that script in
/fpcbuild/install too), or put this functionality
to Makefile.

Comments, opinions?

Tomas

Hi

Definitely correct. The included checksum of the fpcbuild tarball becomes invalid.
Until now, I have no idea about a "clean" solution. The result is a warning dialog after the download with fink, which might lead the uninformed user into downloading the tar ball again and again. To circumvent this, I would submit an updated version to fink.

If my assumptions above regarding how it works are correct, my suggestion would be: 1) Add current files to trunk and merge to fixes.

I am not sure about trunk. I thought trunk is 2.1.* and this is 2.0.4 only. But you know better.

I would prefer tar.gz, since it is smaller.

4) If needed, the files might get updated with new checksums and committed to SVN (but not to the release branch - only trunk and fixes) by somebody.

That sounds ok. The main point is to submit updated versions (paths and names of tar balls and MD5sums) to fink, which I would do after the final 2.0.4 version is ready. Keeping the updated version in the fixes branch would serve for documentation. However, this is their only purpose, since the versions in fpcbuild are not used in any way.

I have a script that supports me when preparing the bootstrap compiler tar ball, which also calculates the MD5sums. I hardly dare to publish that, since it is more like a ToDo list (:-) Basically, putting final version to trunk and fixes should be good enough.

Comments, opinions?

It would be easier, to keep the .info files somewhere else, outside of fpcbuild. Is this possible/feasable? I do not know, who put them in fpcbuild in the first place and for what reasons.

Tomas

Schindler Karl-Michael wrote

Am 20. Jul 2006 um 22:33 schrieb Tomas Hajny:

.
.

Will do it like this next time then.

OK.

OK. As a next step (probably after 2.0.4, but preferably immediately afterwards, so that it isn't forgotten ;-) ), I'd recommend trying to clean up and generalize the script, so that it can be submitted to SVN and possibly used by other people too. As part of this, the current .info files could be transformed to templates (similar to install.sh processing in makepack). The FTP paths would only be supplied as parameters of your script at that time (their validity could be optionally checked at that time from the script by trying to list those directories to avoid typing errors).

Our repository is the most reliable place (permanently distributed to many machines :-) ), everybody knows it and has access to it, and it should include all resources needed for building, so that's OK. However, we might really want to only keep some templates there in the future and fill-in the dynamic part during the build process.

Tomas