Re: roken merge

[Derrick J Brashear <shadow@dementia.org>]

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...

> If, however, the heimdal-0.3a/libroken-xx directory didn't exist, then
> you would use the installed version instead. If nothing exists,
> then complain to the user.

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.

> heimdal-0.3a/libroken-xx
> (which could also include editline and perhaps com_err)

com_err doesn't belong with roken. sl probably belongs with editline,
maybe with com_err

> heimdal-0.3a/libopenssl-xx

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.

> where libroken-xx would be a full distribution, with its own configure 
> scripts, etc.

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


> Then again, I can only think of two extra packages (perhaps there are
> more, but I can't think of any right now). Is two extra packages too

com_err, roken, maybe sl/editline separate from com_err, probably
applications like telnet/ftp/r* in a separate package also.

> much? Two library packages is nothing compared with what is required
> for some Gnome applications.

correct, but the gnome situation is a real pain, going there would just be
horrid.

> c) it makes packaging harder, especially if b) is true. Having
> duplicate source code, if not duplicate libraries, it multiple
> packages is a pure waste. Especially if the source code is the same...

the whole situation is messy.

-D