incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@googlemail.com>
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 
alternatives.

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.

Juergen

Mime
View raw message