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

Reply via email to