-----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 ]
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 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). In any case, it is a no-no for a Linux distri to ship binaries you just got. And not everything is 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 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). 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. > >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. 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? > >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 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.. What if you need to fix bugs *before* a new version of OOo comes out upstream? > >Again, I am not working for a Linux distribution anymore, so that's mostly > >a guess of mine. Perharps someone can tell whether that's correct or not > >in his/her case. > Any distros listening? Yes. me. (Debian) > >I will cowardly let the Debian guys answer this ;-). > Yes, Debianists, please comment ... I'll do. That's complete bullshit. 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 natively supported, not though alien'ized packages which can have arbritrary amounts iof bugs through conversion. 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) > >Yup. In my honest opinion, if you really want to build packages, it should > >be done the regular way, on top of a "make install". > That implicits, to be able to work as root on a dedicated machine, while > only wanting to develop OOo ... Wrong. See Erics answer. > >... 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. Of course, development of libraries makes it needed that it changes sometime, but then the SONAME changes. Like libcurl.so.2 -> libcurl.so.3. libfreetype6 is an exception, it a long time was buggy iin this respect, but bugs appear everywhere, even in OOo. 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*. > >>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, > - being different just to be different (without good technical reasons) > is IMHO stupid, No one denies that. > - 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". OSS can also be commercial (i.e. sold). [ 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 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 these worries there. ] Regards, Rene -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoRBh+FmQsCSK63MRAgi9AJ9FEE+ffTrvPLY2hzbMpt0dtlNwiQCcCjBv PE2mApu95+5iXeoWeNyiFO0= =NcZc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
