Re: [Apertium-stuff] Regenerating bel-rus tarballs
On 7 August 2017 at 12:28, Anthony J. Bentley wrote: > Most package systems do not support version control checkouts. Maybe > Debian does. I know OpenBSD does not. > > *Every* package system supports tarballs. > That's true and I agree tarballs need to exist, but... > I cannot think of a single instance as a packager when I would have > preferred an upstream to *not* pregenerate configure. > config.guess specifically bit-rots rather quickly. OpenBSD port builds even wholly replaces the provided config.guess because of this issue. The other generated files have also been known to bit-rot. These days, Debian's guidelines asks for non-generated sources, because "This rebuilds all auto-generated files to the latest version ones and provides better supports for the porting to the newer architectures". The same holds for Fedora / CentOS / RHEL: "...suggested that such code be regenerated as part of the build process." > 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. We will continue to provide tarballs. Nobody is trying to block that, not even me. I just want the nature of the tarballs to be more raw, to aid portability and avoid bit-rot. -- Tino Didriksen -- 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
Re: [Apertium-stuff] Regenerating bel-rus tarballs
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
Re: [Apertium-stuff] Regenerating bel-rus tarballs
On 7 August 2017 at 04:42, Anthony J. Bentley wrote: > Could the SourceForge tarballs for apertium-bel, apertium-rus, and > apertium-bel-rus be regenerated, please? > > They should: > - be named apertium-$L-$V.tar.gz (without SVN revision) > - contain a subdirectory apertium-$L-$V/ > - contain a pregenerated configure script Done. 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. 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. 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. -- Tino Didriksen -- 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
[Apertium-stuff] Regenerating bel-rus tarballs
Hi, Could the SourceForge tarballs for apertium-bel, apertium-rus, and apertium-bel-rus be regenerated, please? They should: - be named apertium-$L-$V.tar.gz (without SVN revision) - contain a subdirectory apertium-$L-$V/ - contain a pregenerated configure script "make dist" will do the right thing, I think (but I don't know autoconf). I would like to package them for OpenBSD without special casing them. Thanks! -- 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
