On Wed, Jun 15, 2011 at 19:47, Tor Lillqvist <[email protected]> wrote: >> There has been conversation about hosting this at apache-extras.org, >> 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 packages. >> 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 loading). 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 package. Cheers, -g
