incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Bootstrapping a build
Date Thu, 16 Jun 2011 00:34:51 GMT
On Wed, Jun 15, 2011 at 19:47, Tor Lillqvist <> wrote:
>> There has been conversation about hosting this at,
>> but ... what do the TDF/LO folks do? Are they just using dmake from
>> the OOo repository, and hoping that it won't go away?
> We have independent repositories so how would dmake go away?

I made an assumption that you use dmake from OOo, effectively as an
external tool. If you made a copy, then hey... Apache could just point
to yours (instead of making yet another copy over at apache-extras).

>> Have they moved away from dmake?
> Not much more than OOo has. Of course we are merging in any work on
> moving modules to gbuild if/as you do it, and doing some work on it by
> ourselves, too.

Gotcha. And it sounds like you guys have the same goal, which means we
could do "all the work" here at Apache to get rid of dmake usage, and
then you guys can lift that work into your repository.

>> If not, then where are the FreeBSD and Debian getting the code from?
> Well, at least Debian got it from OOo, as building OOo/LO is the only
> purpose of dmake in Debian, I think?

Seems like, yeah. So Debian could switch their upstream over to the LO
repository (assuming OOo goes down before they can remove their
dependency upon the tool), until it finally gets deprecated from all

>> Can't we just use it from there?
> For people who build on Debian or derivatives, sure. But for other
> distros, Windows, MacOSX you would need to provide dmake packages. Or
> make downloading a dmake tarball and building it part of the build
> mechanism, if that is acceptable from a "license purity" point of
> view.

It is fine to tell people "you need <this> tool to build an Apache
program". We use the entire GNU toolchain for a number of projects.

The concern arises when we force an end-user to use a license more
restriction than ours. Packagers may require non-permissive tools (eg.
GCC), but the result will be under the ALv2. The packager may *choose*
to build certain optional features (that are non-permissively
licensed) and deliver that to the end-user.

The key is being able to provide an end-user with a binary under a
permissive license. We can have features that depend upon (say) LGPL
libraries, but those dependencies have to be optional (eg. build
switch or certain types of run-time configuration and dynamic

So in this scenario, we tell people "you need the dmake tool", and
they have to go fetch and build it. We don't have to do anything in
OOo to do that fetch or build. That is simply part of the dmake


View raw message