Hi Tino, Thanks for updating the tarballs.
I have to say, I find the rest of your message troubling. Tino Didriksen writes: > But, ideally you should not use the tarballs for anything. They're a last > resort option for ancient or weird setups that for some reason can't use > svn directly. I maintain dozens of packages for OpenBSD. Although I do my best, it's simply not possible for me to be intimately familiar with the development status of every single one. I rely on upstreams to use their judgment to publish stable releases that they would like distributions to package. > These days, all you need to know to package something is the svn (or git) > path and revision of the release. Much easier for everyone involved. Most package systems do not support version control checkouts. Maybe Debian does. I know OpenBSD does not. *Every* package system supports tarballs. > Tarballs will bit-rot. We know from experience that the pre-generated > configure script will stop working after a few years, whereas if you take > raw Autotools or CMake files and let the tools generate for your exact > distro and setup, then it'll work much better. What experience are you talking about? My memory of apertium build system problems contains examples like https://sourceforge.net/p/apertium/svn/41387/ and https://sourceforge.net/p/apertium/svn/48255/ . These weren't problems in the generated configure/Makefile.in--they were problems in the underlying autotools files. And they were trivial for end packagers to work around (patch the generated Makefile.in and pass an environment variable to configure, respectively). Having to rerun autotools would have been more hassle, not less. I cannot think of a single instance as a packager when I would have preferred an upstream to *not* pregenerate configure. Autotools, unlike POSIX shell, is *not* standard, and it bitrots all the time. Because of that OpenBSD has to include 16 versions of autoconf and 9 versions of automake in the package infrastructure. It's a real hassle to figure out which one is needed when an upstream doesn't provide a pregenerated configure script, because many autoconf scripts are incompatible with either older or newer versions of autoconf. I'm happy that apertium has been getting so much activity lately. I'm happy that the unofficial Debian repos seem to help. But if apertium decides to *only* cater to Debian nightly builds, and not release even occasional tarballs, I will be unable to keep apertium packages up to date on OpenBSD. -- Anthony J. Bentley ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
