OOo 3.1.0 Build-Depends: move from universe to main

[Chris Cheney]

These packages are build-depends of the new OOo 3.1.0 package.

Currently I have OOo 3.1.0 set to use the internal copies of these libraries, but will set it to use the external version with the next upload.

[Martin Pitt (pitti)]

Moving conversation from private mail to here; Chris' reply:

On Wed, 2009-05-06 at 10:02 +0200, Martin Pitt wrote:
> Hello Chris,
>
> Chris Cheney [2009-05-04 12:03 -0500]:
> > As far as I know I believe the packages below were only added to main
> > for OOo so probably could be demoted to universe and be replaced by the
> > new packages listed. Do they need MIRs written up as they are
> > essentially just forks of packages already in main?
>
> They don't need MIR wiki pages, but please open a bug report and
> subscribe ubuntu-mir, with the list below. Then we have a track
> record.
>
> It just seems strange to me why the packages were forked in the first
> place? What's wrong with using the standard packages? Duplicating code
> is always nasty and a maintenance nightmare, so we should think twice
> before we do this IMHO.

Well they make patches to programs they use and the normal build
procedure is to just use all of the 3rd party code that is shipped in
the OOo tarball. Those were split out in Debian and this is the result.
Long term it would definitely be a good idea to get all of those things
merged back with upstream if at all possible.

[Martin Pitt (pitti)]

Right, I understand that they sometimes make patches, but usually they should be applied directly to the original package and fed back upstream, no? How come that we could build OO.o against the system libraries so far?

I have to say that splitting out OO.o specific libraries into separate packages is much worse than having internal copies of them, since that encourages other packages to use the -oo.o variants as well and thus make the mess even worse.

[Chris Cheney (ccheney)]

I am not 100% certain but I think that in this case they modified these for OOo 3.1.x. There have been other libraries in the past that had modifications but at the time we were still using mostly internal copies so didn't run into that issue.

I can continue to just use the internal copies if that would be preferred.

Chris

[Chris Cheney (ccheney)]

I forgot to mention that since Debian has now uploaded OOo 3.1.0 into unstable they have also moved these packages to unstable as well. So the potential for other packages to use these regardless of whether we stick them in main is still there.

Chris

[Chris Cheney (ccheney)]

Martin,

So what do you think I should do about this? As this is already done for Debian it is a point where we would diverge if we don't build using the external copies and would have the external copies in universe in any case.

Chris

[Martin Pitt (pitti)]

IMHO they should have never made it past Debian NEW, since this is just hilarious from a software architecture point. But *shrug*, if these libs maintain "themselves" through Debian, and it avoids a delta, let's do it.

[Martin Pitt (pitti)]

It seems that the current karmic OO.o does not yet pull those in?

[Martin Pitt (pitti)]

flute-openoffice.org ack; package was renamed in Debian from flute-1.3-java, so the latter can be removed together with its two rdepends (liblayout-java and libpentaho-reporting-flow-engine-java)

[Martin Pitt (pitti)]

whoops, flute needs default-java conversion, it still uses gcj.

[Chris Cheney (ccheney)]

It's currently disabled in Karmic OOo so that I could make sure the rest of the packaging worked well before the other packages were processed. I can re-enable usage of the external libraries easily.

Chris

[Martin Pitt (pitti)]

-- karmic/universe i386 deps on liblayout-java:
libpentaho-reporting-flow-engine-java

(no other rdepends)

so this source package can be removed entirely once pentaho is moved.

Package is FTBFS and needs conversion to default-jdk. Interestingly, debian/rules already uses openjdk, but build dependencies don't reflect that.

[Martin Pitt (pitti)]

pentaho-reporting-flow-engine has no reverse dependencies at all, thus I removed it from Karmic.

pentaho-reporting-flow-engine-openoffice.org is FTBFS because of liblayout FTBFS, and needs conversion to default-jdk.

[Martin Pitt (pitti)]

liblayout removed from the archive, no reverse dependencies left.

[Martin Pitt (pitti)]

jcommon-serializer removed from karmic, no reverse dependencies left. Package needs gcj -> default-jdk migration, but is fine otherwise.

[Martin Pitt (pitti)]

libloader-openoffice.org needs gcj->default-jdk migration, it's fine otherwise.

libloader demoted to universe due to no rdepends in main.

[Martin Pitt (pitti)]

libxml-java removed from karmic, no reverse dependencies left.

libxml-openoffice.org needs gcj -> default-jdk migration, it's fine otherwise.

[Martin Pitt (pitti)]

librepository removed from karmic due to no rdepends.

librepository-openoffice.org needs gcj->default-jdk migration, otherwise okay.

[Martin Pitt (pitti)]

libformula removed in karmic (no rdepends).

libformula-openoffice.org needs gcj->default-jdk, ok otherwise.

[Martin Pitt (pitti)]

libfonts-java removed from karmic (no rdepends)

libfonts-openoffice.org needs gcj -> default-jdk, ok otherwise.

[Martin Pitt (pitti)]

libbase-openoffice.org needs gcj->default-jdk, otherwise looks harmless.

[Chris Cheney (ccheney)]

I have converted them all over to default-java and uploaded them. The i386 buildd has a bit of a backlog at the moment but hopefully will have them built soon.

[Martin Pitt (pitti)]

layout binary-NEWed and moved to main.

[Martin Pitt (pitti)]

Promoting other packages while checking them.

[Martin Pitt (pitti)]

pentaho is in dep-wait, needs a publisher run for bringing liblayout into main first.