Rene,
Rene Engelhard wrote:
http://qa.openoffice.org/issues/show_bug.cgi?id=37034
So, obviously the Dev.Guide is non-free. I wouldn't say that OOo is
non-free because of this. In this sense, Debian can obviously
redistribute the OOo SDK without the Dev.Guide only.
That's what we do now but it still means repackaging the source since
What needs to be done to simplify this process?
That this stuff is free so I don't need to remove it? :)
->Frank Peters, Juergen Schmidt: Could you please comment on any license
plans regarding the Dev.Guide?
I didn't see bad effects, but didn't dig deep into it. Even if there were issues
I wouldn't be able to use gpc...
It seems, that already have had a good experience with basegfx. Did you
provide patches for removing gpc?
Well, there's already -disable-gpc. That I can use. The gpc stuff thankfully
isn't in-tree anyway so it doesn't matter that much. But I can now do a patch to
remove gpc support completely, yes.. should be also removing stuff from
configure
and removing #ifdefs...
Reducing code is IMHO always a good thing. So, lets see what Thorsten says.
No, it's not. It's an issue for any serious admin.
You don't want to have any user set the link youself, you want to add it
globally and be done with it. That's the same case here, I could package it
but let the users enable the plugin but that IMHO is bad.
So, this is an OOo issue independent of any distros needs. Obviously it
has not been regarded yet to be severe enough to get fixed. This has
nothing to do with our discussion.
It has. Because atm the mozilla plugin is useless for serious
distributions/admins.
Please treat this as a regular show stopper. If this is a serious
problem for administrating Debian OOo, than it is for OOo OOo or
StarOffice as well.
well, it changes ABI...
SAL is supposed to encapsulate all system dependent file operations, the
comment in the issue states, that all necessary types are already 64
bit. Turning on LFS for SAL is, as far as I understand, not changing
SALs ABI, as non system implemented function is passed through. So, I
have to admit, that I do not which ABI you are talking about.
Err. *If* you build with LFS, build *everything* with it...
in any case, irc snippet, I didn't dig much into there, but:
12:59 < asuffield> _rene_: note that it's an ABI change
13:00 < asuffield> a few of the file-related structs change size and offsets
13:00 < asuffield> (plus off_t itself, of course)
Even if structs may change size or anything, it does _not_ matter if
they are not used. And even if they are used in a private way (not
exposing it at the API), I can not see any problem. Is there somebody
with a more deep understanding (->Tino, Hennes, Oliver, Heiner)
listening and can comment?
Pushing it upstream is nice and is done, but it might be that we need the
fix now anyway for further testing of the debs, fixing a
release-critical bug, preparing for the release, help the users
suffering from the ug *now* etc.
As said, the real code issues still seem to origin from your changes.
No, I didn't change the plugin in any way (well, we do with michaels patch now,
which doesn't work reliably either)
It simply doesn't work if you eant to enable it globally.
So, you mean that from your point of view this issue is release
critical, while the rest of OOo does not think so?
yes. That's why I neeeded to disable the plugin *completely*. No plugin
at all in my packages.
So it is not a stopper, you found an ugly but working solution!
The license stuff is more ugly, but should be solvable one or the other
way also.
Some things even can't be gotten upstream. Like FHS support. If you have a good
idea how it's possible to add it without breaking your stuff (or mine if you
change something) please tell me. Not that fully FHS'izing OOo does work
OOos standard builds are AFAIK fully FHS compliant. The problem is, that
you change OOo to match your distribution and to become a bundled product.
For you. Not for distris.
The FHS does *not* allow /opt for distris. /opt is for third-party add-ons.
Like for you.
distris have to use /usr/lib, /usr/share, /etc, /var etc.
(which I currently do using some symlinks, hacks, etc, and teh config still
isn't in /etc
and the arch-indep stuff still is in /usr/libn/openoffice/share..
AFAIK, /opt is for unbundled software, while the other directories are
for bundled stuff. You may very well create a OOoForDebian and release
it as unbundled software. And this is exactly the point I wanted to
make, why do you want to release it as bundled?
Because we are bundling it with the rest of the system and want integration?
And because /opt is forbidden for distris.
See above. You could very well ship a stock build from OOo (assuming
that .debs would be provided), extending it with some custom system
integration, basically not loosing any functionality and reducing your
burden to always need to build everything!
There was _not_ yet any stringent argument that you need to build OOo by
your own. Only reason was, that this is what distros do. Thinking about
it, I can not see any reason, except for historical ones!
distributions (not me) don't ship db4.2 anymore so they need to maintain own
patches to use db4.3/4.4 which can't go upstream..
At least the numbering (minor update only) implies compatibility, so
what are the patches for?
API changes in db. They change API between minor releases which is also normal
for other
stuff. Or change db on-disk format (which thankfully isn't the cas ehere for
OOos needs)
Does that mean, that they did change the API incompatible in a MINOR? If
it did not change incompatible, than there is no problem anyway.
Yes.
So, SONAME is not of any help here anyway. The db ABI seems to be
unstable / unreliable. I can only see two solutions, either link hard
against one particular version (which is unlikely to be available on all
supported distros), or ship it privately.
A release candidate accepted by the OOo community as "stable" should be
good enough for Debian as well as for any other distribution. Debian
related issues might be fixed or not, depending on severity and good
will. It is unfortunately not (yet;-) possible to release a bug free
version.
Yes, but still then you might release a new one *after* a deadline of the
distri.
And you as a disti have to be have th epossibility to backport fixes like the
ones
above if needed. Buildability from sources is a principle in the Linux
distributions.
This is simple, do _not_ rely on release candidates and schedules of
other projects, they may slip. Take the stable product instead.
The point here is just, when moving out the 3rd party stuff, we need to
ensure that our builds still run on the targeted platforms. And we only
provide _one_ build for all x86 Linux, we are just balancing the
differences of the distros. If you have a patch removing 3rd party stuff
>from the Linux builds, while preserving compatibility with the major
Linux distros, I am pretty sure that it is very welcome (and do not
LOL. And Linux distri uses zlib. It is completely compatible and hasn't changes
So, I do not know what is funny about this.
I do. You said that you use internal libs because there may be incompatibilities
and changes. zlib is ooold. It has the same ABI/API for years, every disri ships
it etc. For zlib, that argument is bogus. The same for getopt() in Linux
(glibc contains it..)
Again, if zlib and getopt are as stable and as common as you said, it
must be easy for you to provide patches to not include them in our Linux
builds!
compatibility for AGES. Just an example. Any current Linux distri uses
libcurl.so.3.
More examples?
Did you provide a patch for this? Is it compatible with OOo supported
distros? Than there shouldn't be any problem to integrate it.
Just link with libcurl. I don't need to provide a patch for this.
This is a change and needs a patch. To phrase it differently, for most
developers (many of them working on windows) it is much easier to just
put everything privately into the product and to not make any exception
e.g. for Linux. So, we may can introduce a policy, to treat 3rd party
stuff platform dependent. Opinions? MH?
All system-* patches already *are* in the tree....
(or are going in then they are ready for inclusion)
I don't know what distros you do support for except ancient ones,
all have libcurl.so.3. But that's just an example... zlib is the best one
of all, also getopt.
See above.
Regards,
Rene
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
