[fpc-devel] 2.0.4-rc2 macosx stuff
karl-michael.schindler at physik.uni-halle.de
Fri Jul 21 10:49:32 CEST 2006
Am 20. Jul 2006 um 22:33 schrieb Tomas Hajny:
> On 20 Jul 06, at 21:11, Jonas Maebe wrote:
>> On 20 Jul 2006, at 15:18, Schindler Karl-Michael wrote:
>>> I think the .info files should go to fpcbuild/tags/
>> Tomas, can you this since you are doing all the RC tagging?
> 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.
Definitely correct. The included checksum of the fpcbuild tarball
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.
> 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
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
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.
> 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.
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.
More information about the fpc-devel