Re: roken merge

[Brian May <bmay@csse.monash.edu.au>]

>>>>> "Derrick" == Derrick J Brashear <shadow@dementia.org> writes:

    Derrick> If you force people to build an ever-growing n
    Derrick> prerequisites for arla, heimdal, kth-krb, they're going
    Derrick> to get grumpy. bundling from the same source and
    Derrick> optionally building if you need it is nice but not always
    Derrick> easy

It depends how you implement it.

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.

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.

That way, you could even have a tgz file that contains
heimdal+libroken+etc the same as currently happens, but also
distribute heimdal alone to benefit those who want to compile it
separately (for any number of possible reasons).

eg it could contain

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

heimdal-0.3a/libopenssl-xx

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

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
much? Two library packages is nothing compared with what is required
for some Gnome applications.


I think the current practice of sharing the set of code between
multiple applications is bad, because

a) it makes it harder to compile against another version.

b) it makes it easier for slight differences between
implementations to occur. The last version installed wins.

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

--  
Brian May <bmay@csse.monash.edu.au>