incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: Moving ext_src to Apache
Date Wed, 30 Nov 2011 10:48:52 GMT
On 11/29/11 12:04 AM, Mathias Bauer wrote:
> Am 30.10.2011 19:49, schrieb Mathias Bauer:
>> Moin,
>> thinking a bit about what would be the best to do I would like to sort
>> all tarballs into several categories:
>> (1) external source tarballs with an AL compatible license
>> (2) external source tarballs with weak copyleft license
>> (3) external source tarballs with strong copleft license
> I decided to make things simple. So I just checked in the source
> tarballs for (1) and (2), means sources with category A and B license.
> You will find them in the new folder
> trunk/ext_sources
> Basically we should be able to use this folder in the build once we have
> solved the remaining problems (see below). "By luck" this is the default
> location where the OOo build looks for external tarballs if no parameter
> was set in configure.
> So I made an attempt to build with it (Ubuntu 11.10 64 Bit) and nearly
> got through the build:
> (1) ./configure (no parameters!)
> (2) *no* bootstrap (I took dmake from the system and skipped the
> fetch_tarballs that way)
> (3) build
> I got problems only in three cases:
> (1) berkeley DB was missed in two places
seems that we have overseen berkeley db here. Ok we have to find 

One use case is the managing of extensions (extensions.db, 
uno_packages.db, ...)

And the other use case is inthe help system.

> (2) rhino missed swingExtSrc (this was discussed on the list already,
> maybe we have a solution to fix that?)

This becomes obsolete with the update to a newer Rhino version and the 
available patch.

> (3) I then provided the missing tarballs temporarily and continued with
> the build. Now I got a problem in instsetoo_native (building of deb
> files didn't work, perhaps the system epm doesn't work here, I heard
> that others were more successfull). But the archive install set was
> build and worked!
not out of the box and i went back to use the patched version of epm. 
More work is necessary here to understand the packaging process. And 
it's only a build tool similar to make or dmake.

> That looks as if we are close to a build without external stuff with
> strong copyleft license.
> We still have to define how to deal with the weak copyleft stuff. I
> found the following Category B licenses: MPL, CPL, CDDL. As we still
> didn't get a definitive statement if we are allowed to keep them in svn
> if we make sure that they are not built by default and they are not part
> of our source releases, it seems that there is a common agreement to
> keep them for now and possibly remove them later. Even if we had to
> remove them, we now have an intermediate step that helps us a bit
> forward, IMHO.
i think it will definitely help us for now. And the work on finding 
alternatives is ongoing.

> At this time my checkin does not change anything for the build, but you
> can try it by providing a dmake instance before and not calling
> "bootstrap" as described above.
> Now we can start from there and change our build so that it uses this
> folder by default.
yes, that sounds good to me. I would leave the download opportunity in 
place. That would allow that at least in a source release all configure 
switches would work and won't break anything. But of course nothing 
would be used by default.


View raw message