Re: roken merge

[Assar Westerlund <assar@sics.se>]

Derrick J Brashear <shadow@dementia.org> writes:
> On 16 Aug 2000, Brian May wrote:
> 
> > For instance , you could extract the source code for libroken in the
> > heimdal source tree, and have the heimdal configure script autodetect
> > that and use that.
> 
> Right, but...

Yes, I think we all agree on that this is what we have to do, so

> What if what exists is old and has some bug, or some missing symbols,
> given what we need? What if there have been multiple sets of "we added
> these new symbols" changes? You test for the most recent one, I guess, and
> build it you have to, and lose if you can't.

figuring out if the installed stuff is `good enough' for the current
package is where the problem has moved.  Just testing for the
functions you want to use is cumbersome and might not be good enough,
since you might, as Derrick noted, want to know if it has fixed some
important bug.  Writing autoconf tests for this is too much work (I
don't really want to spend all my time writing autoconf code), so we
would have to do version number comparisons.

> then you *may* end up with apps which need only -ldes, or which need -ldes
> and -lcrypto, unless openssl pulls in all the additional stuff heimdal
> needs, but if so, you need to test for it. possible but of course requires
> consideration. as it is heimdal doesn't match mit for library names, which
> isn't horrible but already is going to make people i work with unhappy
> if/when i stick heimdal under them instead of krb5.

Yes, it's going to be more of a burden to figure out what sets of
additional libraries you need to link with.  Saying that you need to
use libtool and code in the dependencies in the .la file is not going
to sit well with everybody.  The other choice is to have a
`heimdal-config' script à la gtk/gnome.  Getting something that works
with same way as the stuff from the New England rebels would be great.

> do you force the top to run configure in the subdirs, or let it configure
> the subpackages itself? either is a pain, the former because of the added
> complexity of tracking how to configure subpackages, the latter because of
> the vast amount of time you end up requiring to configure

Currently, we do number one, and we have a macro that's called from
the top ocnfigure.in.  You of course also need to package the set of
autoconf-macros with all the sub-packages.
> 
> com_err, roken, maybe sl/editline separate from com_err, probably
> applications like telnet/ftp/r* in a separate package also.

The libraries that are used elsewhere it's the important part.  I
guess telnet/whatever other applications also are separate in some
logical sense, but they're not eligible for independence yet, if
ever.  If you only want/need some of them, build all and then grab the
pieces that you want, it's not like it's going to take that long on
any recent box to build them.

/assar