Hi, Antonio-- Thanks for your quick reply!
On Sat, May 11, 2013 at 11:15 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote: > > Sometimes I do upload a new tarball to replace a bad one. But this only > occurs during release time. After the release is stable I don't change them > anymore. This may affects your system. Maybe I have to update something in > SourceForge to update the checksums? Not exactly. Although many developers publish checksums for their packages (a very good practice, IMHO)--i.e. they will place a 'foo.md5' and/or 'foo.sha1' file, containing checksums, along with their foo.tar.gz in the download directory. And possibly Sourceforge can automatically generate those for you. But in any case that's not the issue here. The way source packages work on Arch Linux (and I think all major Linux distributions follow a similar practice, though the details differ), someone in the Arch Linux community (the 'package maintainer') decides to create a package, such as im. They find out the steps needed to compile the software, and then create a package specification file called a PKGBUILD. Somewhere in this process they obtain a checksum for the source tarball; I think if the upstream developer provides a checksum, they will start with that, and put it in the PKGBUILD, after verifying that the checksum matches for the file they downloaded. If it doesn't match, well, they *should* find out why, though I doubt that everyone does that. So now a checksum is included in the PKGBUILD, and Arch Linux users can obtain the PKGBUILD and use it to build im. So you go to a directory containing the PKGBUILD file and type the command 'makepkg', and the package should be automatically built. The first step is to download the source code; the second step is to call 'sha1sum' or 'md5sum' (or occasionally some other program) on all files that were downloaded; the checksums thus obtained should match what is in the PKGBUILD. If not, the automatic build fails. This is supposed to guarantee that the source code you download matches what the package maintainer downloaded, which in turn should match what the original developer provided. > But what you are saying is that every time you download the same file, > even one after another, the checksum of the two file will be different? Yes, and I build a lot of packages from source; I have never seen this before. > I'm > not familiar using checksums, but this seems to be a SourceForge problem. > Right? I suppose it must be, but it can't be a *common* SourceForge problem. Because all Linux distros use checksums to verify source packages, and a very large percentage of source packages are downloaded from SourceForge. If this were a common problem it would be totally impractical to verify packages in that way. I don't have very extensive experience with SourceForge; I had a project hosted there a few years ago, but it was not widely used, and I was less disciplined as a developer then, so if something like this happened then, I was unaware of it. I am guessing that the tarballs for your projects are built on-the-fly, and that something is happening as they get archived to cause each file to turn out a little different. Perhaps there is some parameter in your SourceForge configuration that you have set to an unusual value? Another thing that occurs to me is that I think SourceForge offers 'build farm' functionality, where it is possible to offer a constantly-evolving 'snapshot' release. But from what you said of your practices, it doesn't sound like you are doing that. In any case, I don't think you could use on online build farm without having taken deliberate steps to set it up. Moreover, I have the impression that you have a very small development team. Even if the download file were a continuous snapshot, the rapidity of the changes I am seeing (1-2 minutes apart over 3 packages) would only make sense if it were a large project with many active developers. So, yes, I think it must be a SourceForge problem, but I have no specific idea of what it is. BTW, I just looked at the PKGBUILD again, and I have an idea. But I'll send this off first ... because if IUP becomes more popular, you should know something about how people are attempting to package your software. -- Matt Gushee ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
