Am Mittwoch, 28. Juni 2006 18:17 schrieb Kay Ramme - Sun Germany - Hamburg: > Rene, > > Rene Engelhard wrote: > > We are going to ship no version of Mozilla... > No Mozilla at all? Neither Firefox nor Thunderbird etc.? Or are you > talking about the suite only?
The "old" suite. > >>> 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? :) > > 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... > >>> - - jurt/doc > >> This is ridiculous, somebody should just remove it! > > > > Maybe, but it's there.. > This files do not even get delivered. So, please just create a CWS and > remove them. OK. > > 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. > > 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) > > > > >>> 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. > >> 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. > >>> 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. > >> 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..) > > 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. 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. Regards, Rene -- René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED] http://openoffice.debian.net | debian-openoffice@lists.debian.org GPG: 248AEB73 | Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
