incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <Mathias_Ba...@gmx.net>
Subject Re: Moving ext_src to Apache
Date Mon, 28 Nov 2011 23:04:39 GMT
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
(2) rhino missed swingExtSrc (this was discussed on the list already,
maybe we have a solution to fix that?)
(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!

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.

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.

Regards,
Mathias


Mime
View raw message