Hi Rene,
Rene Engelhard wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[ late answer, I needed time to *try* make my answer polite, sorry if that
doesn't happen all the time in this post, for the record I am one of the
two people making the Debian packages, currently the most active one of
both ]
just saying this is IMHO already un-polite. I think I am personally open
for any discussion, as long it is based on arguments and facts. The
moment you start being un-polite I immediately stop answering, and you
may discuss with whomever you want (actually achieving nothing or may be
the contrary). I will not repeat this.
Kay Ramme - Sun Germany - Hamburg wrote:
1) Suitability - Not all the Linux distributions follow the same purposes.
Some are for desktop users, some are for generic servers, some are for
specialized purposes like firewalls, application servers or clustering.
Some try to imitate Windows or Mac OS X, some try to get away from other
OSes as much as they can. A lot of changes are made to give personality to
the distributions.
That does not necessarily mean, that they need to patch or change
anything in the provided products, does it? At least OOo provides
extensive configurability to actually change everything, without needing
to alter a single line of code.
Of course that does. There's bugs in OOo. Bugs need to be fixed.
Distributions and OOo have different release schedules. Or: You have
Release schedules shouldn't be the problem, I would expect Debian to
always ship the latest stable version.
some additions you *need* for whatever reasons.
And you don't build some of the optional stuff.
You have various UNFIXED security things open (Mozilla to name the most
prominent one).
Isn't Mozilla providing binaries of products with latest security patches?
In any case, it is a no-no for a Linux distri to ship binaries you just
got.
For what reason?
And not everything is configurable...
So you patch what is not configurable?
2) Coherence - A Linux distribution is a coherent set of software. Even if
documents like FHS and LSB state a lot of things, like the place where
files should go, there's room for a lot of variations. As long as the
various choices are coherent within the same distribution, that's okay. A
lot of changes here and there attempt to have all software follow common
conventions.
I think you hit the point here, IMHO Linux does not only need to be
coherent inside the distributions, but also _overall_ ...
Yes, but it also needs coherency inside the distro.
That is what Eric said ...
That also means that you don't need to ship every lib inside the
package, bloating it for example. Or you have to integrate with
distro-specifics (like sensible-browser, run the browser you have
choosen system-wide in the env or set with the BROWSER envvar, just for
example, that's a minor one).
This seems to be some kind of system integration, isn't it?
Or take pyuno. You need a internal python and can't use the systems'
python modules, not to mention the stuff isn't simply usable by the
systems' normal python.
Just take a look from an ISVs perspective.
3) Corrections - A lot of the work is made to fix problems in the packaged
software itself. Why are such changes not done upstream at the initial
software projects? They are done upstream too, but since it's a much
slower process than a quick fix in the distribution, upstream corrections
are done usually much after the distribution is in the retail stores.
This is understood, but is IMHO the wrong approach and really should be
the exception, I think at least we at OOo are very willing to support
the distributions to get their fixes merged in upstream.
LOL. I have many counterexamples here where bugs ARE NOT GETTING FIXED
after submitted.
I can look for them.
Are you only submitting bugs or fixes as well?
And anyway, you have an other release schedule than distributions. How
is a distribution supposed to backport bugfixes for their next release
if there's only binaries you ship and have to wait for a new OOo release
(which might not fix those bugs after all) although the distris deadline
is earlier?
AFAIK, we are providing respins of the current major version in regular
(mostly quarterly) intervals. We also provide respins of older versions
if needed. There is IMHO no need to backport any patches, just use the
latest stable version.
In short: I suppose you bring a big problem to distributors by bringing
already packaged software.
I think I disagree again, as you said, distros may just install and
repackage OOo. IMHO, the most prominent reason for repackaging is to
change OOo to be a "bundled" product, while the packages we are
providing are "unbundled". The point being, that there IMHO is _no_ real
or good reason to have products (applications) to be "bundled", except
that this is what distros do.
No, the reason is that shipping binaries is bad. Every distro rebuilds
Repeating thinks don't make them valid per se ...
from source. What if a security thing pops up? You didn't care or issue
updates for the last issues (neon, curl, mozilla, ...) for libraries you
use..
If we (OOo) don't care, you probably do not get a fix for the OOo code
anyway. Regarding the library issue, you are right, so. And I have to
admit that I do not have a quick fix at hand ...
What if you need to fix bugs *before* a new version of OOo comes out
upstream?
I would expect that you just do it like everybody else, stumble over a
problem, find a fix and push it upstream. Or did I misunderstood you?
I will cowardly let the Debian guys answer this ;-).
Yes, Debianists, please comment ...
I'll do.
That's complete bullshit.
OK, another comment like this, and you may talk to anybody else ...
Debian (and it's derivatives) is a distribution like everyone else -
dpkg/deb even was there *before* rpm afaik. Even if not, Debian should be
Does that mean anything?
natively supported, not though alien'ized packages which can have arbritrary
amounts
iof bugs through conversion.
It seems that you are somehow personally offended ...
There *is* support for Debian in your build system, but you don't enable it...
(Or you at least don't publish the resulting files for deb support)
As I said, there were plans to provide .debs. But, isn't that
uninteresting for you anyways, as you are going to build OOo by your own
anyway?
... and we would have the DLL conflicts nightmare in Linux too (see
"Coherence" paragraph) ;-).
So, we already have that par excellence ... :-(. Exactly this is the
reason, why we (being an ISV) have to bring all this 3rd party stuff by
our own, basically being a kind of a mini distro on Linux.
No.
Dynamic libraries under Linux have SONAMEs indicating
binary-compatibility. The Windows DLL hell is about stuff just named
.dll without indications about of that.
SONAMEs are fine if used consistently and changed if needed.
libfreetype6 is an exception, it a long time was buggy iin this respect,
but bugs appear everywhere, even in OOo.
freetype was just one of many problems ...
Yes, if you link against libcurl.so.3 you need libcurl.so.3 and not
.so.2 but libcurl.so.3 could be installed. Or you link statically with
the curl in your build env. But *not ship it in your source*.
how would I express dependencies generically ?
and one wouldn't need to
wait until a particular distribution would provide the latest package of
a particular product ...
That's the Windows way, not the Linux way.
Two points here,
- this could very well be one of the most prominent reasons for Windows
success in both worlds, the open source world and the commercial world.
ROTFL. Windows is in no way part of the Open Source world since it is
closed source. And Commercial is a wrong word anyway for "proprietary".
This is true.
OSS can also be commercial (i.e. sold).
That is what I wanted to say.
[ If you want, we can discuss that at OOoCon, I hope my paper about "OOo
and GNU/Linux-distributions" will get accepted - if you want that too
I would like to do that.
and maybe some of the points clarified you might want to try to
influence the committee so the accept the paper - so I can add more about
I do not think I have any influence on the comittee, except being a
project lead.
these worries there. ]
Regards,
Rene
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
