Ticket #1066 (assigned defect)
athena-dist has bitrotted; it's not 1995 anymore
| Reported by: | jdreed | Owned by: | achernya |
|---|---|---|---|
| Priority: | normal | Milestone: | The Distant Future |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
In addition to #1064, I think a lot of athena-dist is actively harmful these days. We should consider cleaning it up and or moving it to HTTP served out of a locker somewhere? There are probably Historical Reasons(tm) that need to be considered.
Change History
comment:2 follow-up: ↓ 3 Changed 12 years ago by andersk
aclocal automatically copies the necessary macros into the m4/ directory, so I’m not sure it’s necessary or appropriate to version-control that in some other way (for the same reasons that our giant aclocal.m4 was Wrong).
We just need to make sure that the macros are installed on the system (either by the corresponding upstream library packages, or by debathena-aclocal) at the time that autoreconf is to be run (whether that’s package build time or tarball generation time).
comment:3 in reply to: ↑ 2 Changed 12 years ago by andersk
Replying to andersk:
aclocal automatically copies the necessary macros into the m4/ directory,
Oh, I forgot, this only happens with ACLOCAL_AMFLAGS = --install -I m4 in Makefile.am, which requires automake ≥ 1.10.
comment:4 Changed 12 years ago by achernya
That sounds fine, because the oldest releases we should still be targeting going forward are squeeze and lucid, both of which have automake 1.11.
Are you sure you need those flags? I appear to have gotten them automatically with AC_CONFIG_MACRO_DIR([m4]).
comment:5 Changed 12 years ago by andersk
hesiod/Makefile.am does have ACLOCAL_AMFLAGS = -I m4, which you probably added at the suggestion of
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
The AC_CONFIG_MACRO_DIR([m4]) is enough for libtool to install itself into m4/, but libtool is a special case here; other macros won’t do that automatically without --install.
comment:6 follow-up: ↓ 7 Changed 12 years ago by jdreed
I'm fine flipping out and providing pkg-config for everything we're upstream for. Why isn't /usr/bin/krb5-config the right answer? Won't using another m4 file merely change the problem rather than fix it?
comment:7 in reply to: ↑ 6 Changed 12 years ago by kaduk
Replying to jdreed:
I'm fine flipping out and providing pkg-config for everything we're upstream for. Why isn't /usr/bin/krb5-config the right answer? Won't using another m4 file merely change the problem rather than fix it?
krb5-config still requires some amount of "manual" handling, in that it is a krb5-specific utility.
krb5 1.12 will ship a pkg-config file, but that's still a ways off (I thought it had made it into 1.11, but it looks like it did not.)
Since #1064 has now been fixed by uploading a new hesiod to athena-dist, I think the right solution is for us to figure out how to release tarballs for our various bits of code.
Hesiod was released with a brand-new build system based on both autoconf and automake, which worked great. In the process of doing this (admittedly difficult) conversion, I found a lot of things the previous-generation configure scripts failed to check.
The first step to making a new configure is to run autoscan. This generates a configure.scan, which can be moved to configure.ac and then edited appropriately. This would require pulling in the various specific tests the package may have that autoscan can't detect.
Switching from Makefile.in to automake is fairly straightforward, hesiod can serve as a template.
Unfortunately, this packaging scheme is partially blocked by #334. It would be nice if all packages could be built with "--with autoreconf", so that we don't have to do a strange dance with autoreconf -iv in checkouts, and can instead run debuild, but that will fail on machines that don't have debathena-aclocal. This sucks for users that want to build our packages outside of our environment, and is not suitable for upstream releases anyway.
From looking at debathena-aclocal, most of the macros appear to be bitrotted. The hesiod macro is now useless, as hesiod ships a pkg-config file. Zephyr will soon ship a pkg-config file as well. For kerberos, detection, we should instead use Russ Allbery's excellent krb5-config.m4. For anything else, we should provide pkg-config files whenever possible.
As for the distribution of these macros, it's reasonable for them to be in a centralized location and then copied into the m4/ folder of each package. I suppose we could do this with symlinks in svn, although I don't know how make dist will react. In the future where we've moved to git the m4/ directory could be a git submodule in each package.