Re: [dev] Packaging process
Le Lundi 26 Juin 2006 17:40, Kay Ramme - Sun Germany - Hamburg a écrit : > > Okay, we have diverging opinions on this point ;-). > > Professional answer :-), ;-) > I think I had implicitly the hope that you > might be able to explain to me the motivations of the distributions, to > always rebuild, repackage and patch everything. I already talked to some > guys about it, but did not get it. Okay, I think I can sched some light on this: I - "Good" reasons 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. 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. 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. II - "Bad" reasons 4) Not invented here - We all think that we have better ideas than our neighbours, so we want them our way. Distribution makers just follow the same behaviour because they have an ill ego just like every computer scientist. 5) Hiding the dust under the carpet - Some changes are just here to prevent other problems from appearing, when the cause for such problems cannot be located or eliminated in a reasonable time. > But, in the end, what is the difference between rpm-install and make > install (despite that some products may not be able to de-install > themselves)? There's a deep difference between "make install" and "rpm -ih". The first one does not need an installed software database. The second one needs a coherent RPM database, with all software dependencies satisfied in the right order. All the packaging process is made for usual software that installs with "make install". Not for software that installs with "rpm -ih". The "build systems" (computers) at the distributions usually have correct "build dependancies", i.e. software needed to build : make, gcc, autoconf, glibc, patch, ... but not "software dependancies" that a RPM needs to be installed. It's not even sure that "rpm" itself is installed on such machines... In short: I suppose you bring a big problem to distributors by bringing already packaged software. 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. > AFAIK, the most prominent reasons for distributions to build OOo by > their own are > - to not include or have any dependencies on non-free software (e.g. Java), > - to change the look&feel, e.g. to replace some icons etc., or "Suitability" paragraph, see above. > - to optimize install sets by removing included 3rd party packages > (freetype, expat, etc.) > - to patch it to be more compliant to the target distribution, > - to change target locations, e.g. to provide OOo as a bundled product. "Coherence", see above. > AFAIK, Debian is officially supported, the LSB recommended way is, to > provide RPMs and to use "alien" on Debian. Ah. I will cowardly let the Debian guys answer this ;-). > That is fully agreed, builds certainly should be usable without the > generation of packages or the need to install them! > (...) > This is IMHO the same as above, builds (without packages) need to be > directly executable! 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". > I tend to disagree here (see above :-), Politically correct answer ;-). > if all products / software would > be provided as packages by their developers, there would be far less > incompatibilities between the distributions, Well, there would be no distributions at all ;-)... ... and we would have the DLL conflicts nightmare in Linux too (see "Coherence" paragraph) ;-). > 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. -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For ad
Re: [dev] Packaging process
Hi Éric, *, On Mon, Jun 26, 2006 at 06:25:17PM +0200, Éric Bischoff wrote: > Le Lundi 26 Juin 2006 17:40, Kay Ramme - Sun Germany - Hamburg a écrit : > [...] > > But, in the end, what is the difference between rpm-install and make > > install (despite that some products may not be able to de-install > > themselves)? > > There's a deep difference between "make install" and "rpm -ih". The first one > does not need an installed software database. The second one needs a coherent > RPM database, with all software dependencies satisfied in the right order. OOo as "vanilla" OOo doesn't have any external dependencies. You don't need to install the rpms to repackage them. rpm2cpio & cpio or any of these archivemanagers can extract all the files for you. > All the packaging process is made for usual software that installs with "make > install". Not for software that installs with "rpm -ih". Packaging process that generates rpms or debs. Then again the question: Why repackage everything, then answer basically is: because distros want it that way. Then my return: So why instead of tar -xvf rpm2pcio *rpm |cpio -idmv? > The "build > systems" (computers) at the distributions usually have correct "build > dependancies", i.e. software needed to build : make, gcc, autoconf, glibc, > patch, ... but not "software dependancies" that a RPM needs to be installed. Well since many of the use these build systems to build packages and these packages are often rpms, how would they do this without having rpm installed? > It's not even sure that "rpm" itself is installed on such machines... > > In short: I suppose you bring a big problem to distributors by bringing > already packaged software. I don't see that problem. Either you can get along with the binaries or you don't. Distributions build on their own. > > That is fully agreed, builds certainly should be usable without the > > generation of packages or the need to install them! > > (...) > > This is IMHO the same as above, builds (without packages) need to be > > directly executable! > > 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". crap. (I*M*HO) When building packages, you install into a buildroot anyway. So you can simply unpack the rpms there and repackage. > [...] > ... and we would have the DLL conflicts nightmare in Linux too (see > "Coherence" paragraph) ;-). Linux has way more dependency problems compared to windows. ciao Christian -- NP: Evanescence - Tourniquet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Le Lundi 26 Juin 2006 20:19, Christian Lohmaier a écrit : > > OOo as "vanilla" OOo doesn't have any external dependencies. > You don't need to install the rpms to repackage them. > > rpm2cpio & cpio or any of these archivemanagers can extract all the > files for you. Yes. You can also install the source RPM and recompile it. In any case, I wouldn't call that something natural nor easy. > > All the packaging process is made for usual software that installs with > > "make install". Not for software that installs with "rpm -ih". > > Packaging process that generates rpms or debs. Yes, I was speaking about the Linux world. I am conscious that Windows users would expect MSI packages and Mac OS users would expect Mac packages. After all, there's no Windows distribution nor Mac OS distribution ;-). That makes both worlds rather different. > Then again the question: > Why repackage everything, then answer basically is: because distros want > it that way. That's correct, but I would reformulate it otherwise : Why not produce packages for Linux? Because it's the distributions task. > Then my return: So why instead of tar -xvf > rpm2pcio *rpm |cpio -idmv? A RPM package is not an archive. Of course you can use it as an archive. But that's deeply misunderstanding the mechanisms of Linux software distribution. > Well since many of the use these build systems to build packages and > these packages are often rpms, how would they do this without having rpm > installed? They have rpmbuild installed ;-). > I don't see that problem. Either you can get along with the binaries or > you don't. Distributions build on their own. Yes, that's nice to have binaries, especially for people downloading them on the OpenOffice.org website. But it should be optionnal. If that makes life more complicated for distributors and for developpers, that's suboptimal. > > 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". > > crap. (I*M*HO) Oh, that's rather unprofessional an answer ;-). > When building packages, you install into a buildroot anyway. So you can > simply unpack the rpms there and repackage. Yes. You can. That's not the simplest way though. The purpose of the buildroot is normally to simulate a user's environment where a software can safely "make install". Here this paradigm is defeated. > > ... and we would have the DLL conflicts nightmare in Linux too (see > > "Coherence" paragraph) ;-). > > Linux has way more dependency problems compared to windows. Uh ? I install my distribution, and all software works smoothly together. Okay everyone, don't feed the troll, please ;-). -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi *, On Mon, Jun 26, 2006 at 08:51:23PM +0200, Éric Bischoff wrote: > Le Lundi 26 Juin 2006 20:19, Christian Lohmaier a écrit : > > > > OOo as "vanilla" OOo doesn't have any external dependencies. > > You don't need to install the rpms to repackage them. > > > > rpm2cpio & cpio or any of these archivemanagers can extract all the > > files for you. > > Yes. You can also install the source RPM and recompile it. > > In any case, I wouldn't call that something natural nor easy. ? The user doesn't have to bother. Either they use the packages provided by $distribution or they take the packages from vanilla OOo. And the packagers who are doing the packages for their distribution should know how to unpack something or how to compile from source. I absolutely do not get your point. > [...] > > Then again the question: > > Why repackage everything, then answer basically is: because distros want > > it that way. > > That's correct, but I would reformulate it otherwise : > > Why not produce packages for Linux? Because it's the distributions task. As stressed multiple times already: Distributions *modify* OOo for whatever reason - "justified" or not. So tell me what should those who want the "original", vanilla OOo get? The source and compile themselves so they can "make install"? You cannot be serious about that. > > Then my return: So why instead of tar -xvf > > rpm2pcio *rpm |cpio -idmv? > > A RPM package is not an archive. It is an archive with meta information. > Of course you can use it as an archive. But that's deeply misunderstanding > the > mechanisms of Linux software distribution. No, its not. You're misunderstanding. OOo's rpms have all that meta-information (dependencies, install-scripts for the desktop-integration packages, a way to relocate stuff, ...) But *you* want to change the package. So you can "flatten" the rpms to an archive and upack that and add your custom meta-information when you repackage it. But since OOo is rather self-contained, there is not much difference between just extracting it or installing it using rpm. (Since you don't intend to keep it anyway when you only install it to repackage) > [...] > > I don't see that problem. Either you can get along with the binaries or > > you don't. Distributions build on their own. > > Yes, that's nice to have binaries, especially for people downloading them on > the OpenOffice.org website. But it should be optionnal. If that makes life > more complicated for distributors and for developpers, that's suboptimal. Now you're mixing up things. If you intend to just run it without installing, that's something completely different from creating cusotm packages for a distribution. You can use linkoo to create an installation out of your build-dir. > [...] > > When building packages, you install into a buildroot anyway. So you can > > simply unpack the rpms there and repackage. > > Yes. You can. That's not the simplest way though. Doing it the other way round (e.g. having to write a spec file to package all the flat files generated using make install) is way harder than doing it the other way round. > The purpose of the buildroot is normally to simulate a user's environment > where a software can safely "make install". Here this paradigm is defeated. No, it doesn't simulate an environment. It is just a directory where an unprivileged user can put the things without the risk of having a broken makefile overwrite important stuff from the buildhost. > > > ... and we would have the DLL conflicts nightmare in Linux too (see > > > "Coherence" paragraph) ;-). > > > > Linux has way more dependency problems compared to windows. > > Uh ? > > I install my distribution, and all software works smoothly together. That is as getting all your software from Microsoft, one single "Distributor". But on windows you can basically get every software from any vendor. If it is labeled "runs on windows XP", you can be pretty sure that it runs (despite the bugs it might have). Now try to apply this to linux distributions. Get a package for SuSE and try to install that on Redhat. At best you can use --nodeps to ignore the different naming-schemes of the packages and it will run. But using switches to bypass deps or other things surely is not the best way on how a package management tool should work. The situation gets worse with older installations. There is no "linux version X" label you could specify. It most likely is "You need version X of glibc" (that is the reason why I cannot use most of the precompiled stuff that is offered, my version is just too old), "furthermore you need $foo and $bar". $foo and $bar themselves require other packages or worse conflict with other packages. (think of sound-severs, desktop-environments,) ciao Christian -- NP: Metallica - Crash Course In Brain Surgery - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: [dev] Packaging process
Éric, Éric Bischoff wrote: I - "Good" reasons 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. 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_ ... 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. II - "Bad" reasons 4) Not invented here - We all think that we have better ideas than our neighbours, so we want them our way. Distribution makers just follow the same behaviour because they have an ill ego just like every computer scientist. Yeah, I know that feeling too ;-), but try to be steady ... IMHO, "Coherence" and "Suitability" can be addressed independent of patching / rebuilding / packaging software products. Non-Coherence over distributions is one of the biggest obstacles ISVs, and I count OOo or Mozilla as ISVs, face when supporting Linux. LSB is actively trying to address this, unfortunately with varying success. I did visit the last DAM (Desktop Architects Meeting) in Mainz (organized by the OSDL), and we did talk a lot about this, so I am not yet sure, that we have any real outcomes ... ;-) 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. 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? I will cowardly let the Debian guys answer this ;-). Yes, Debianists, please comment ... 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 ... if all products / software would be provided as packages by their developers, there would be far less incompatibilities between the distributions, Well, there would be no distributions at all ;-)... So, you are right, that is what I personally concluded several times, when thinking about the subject. And yes, I know that this is a sensitive topic to discuss ... ... 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. 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, - 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. And I want Linux to be successful in both (or more) worlds as well. Thanks for your explanations and comments, I am enjoying the discussions ... :-) Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional comm
Re: [dev] Packaging process
Le Lundi 26 Juin 2006 21:33, Christian Lohmaier a écrit : > ? The user doesn't have to bother. Either they use the packages provided > by $distribution or they take the packages from vanilla OOo. > > And the packagers who are doing the packages for their distribution > should know how to unpack something or how to compile from source. > > I absolutely do not get your point. My point is : why make it unnatural and complicated when you can do it in the normal, regular way? The normal, regular way is to package software that installs with "make install". Currently, if distributions want to do serious changes in OOo, they have to learn the whole build mechanism, scp2 bits, etc, to finally build a package that they will disassemble right away. Of course they can learn how to do that, it's just unusual, since no other software than OOo goes that way. I will stop discussing that here. After all, I am not a package maintainer (anymore) so I am not representative enough to sustain this discussion. > You can use linkoo to create an installation out of your build-dir. I did not know that. So that would be equivalent to a "make install"? Where is that documented? > > I install my distribution, and all software works smoothly together. > > That is as getting all your software from Microsoft, one single > "Distributor". Okay, that piece of discussion is unrelated to main topic. It is even completly off-topic ;-) but interesting, so let's continue with that. Perharps in private if it bothers the others. Yes, you are right. That's like getting all your software from Microsoft. But there are a few differences that make a lot of importance (caution, troll included): 1) In fact, many companies _do_ get all their software from Microsoft, putting themselves in a state of strategic dependancy. 2) The software in your Linux distribution has not been written by the distributor... 3) You have the choice of your distributor. There's real concurrence. 4) A Linux distribution contains almost all the software you might need, it's seldom needed to look outside of your distro. 5) With Microsoft you cannot adapt the software to your needs. You have not the source. > Now try to apply this to linux distributions. Get a package for SuSE and > try to install that on Redhat. No one does that. Software is coherent within ONE distribution. Listen, that's two different approaches. Why not just admit that it's different philosophies, with both their advantages and drawbacks? And, returning to main topic, why try to import into Linux a packaging philosophy that is adapted to Windows? -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Le Mardi 27 Juin 2006 09:57, Kay Ramme - Sun Germany - Hamburg a écrit : > > 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 ... No. I usually do my "make install"s as root, but that's not necessary. You can "make install" to your home directory if you wish. There's a configure flag named "--prefix" for that. > And yes, I know that this is a sensitive topic to discuss ... Yes, and unfortunately sensitive topics usually produce unproductive discussions ;-). > - 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. > And I want Linux to be successful in both (or more) worlds as well. Not sure about what you say, but in any case doing both ways does not hurt... ;-). > Thanks for your explanations and comments, I am enjoying the discussions > ... :-) "me too" ;-) Thanks for your openess. -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Le Mardi 27 Juin 2006 10:10, Janne Johansson a écrit : > > Any package maintainer listening here to confirm or denegate what I am > > saying ? I used to work in a linux distribution, so I think I can express > > opinions on this topic, but some package maintainers might see that > > differently. > > I am trying to fit OOo2 into our sourcebuilding packaging system, and I > agree with your point. > Having to go over rpms feels "stupid" in a way where not everything is > meant to end up at > /usr/local or where linux isn't necessarily implying you use (and like) > rpms. > > If not for those reasons, then for the reason that zillions of other > opensource products happen > to have a "unpack ; configure ; make ; make install" routine well built in > into the spines of us builders. For which distro are you facing those problems? -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Éric, Éric Bischoff wrote: No. I usually do my "make install"s as root, but that's not necessary. You can "make install" to your home directory if you wish. There's a configure flag named "--prefix" for that. Did not know that, thanks. And yes, I know that this is a sensitive topic to discuss ... Yes, and unfortunately sensitive topics usually produce unproductive discussions ;-). Despite this, anybody interested in the "make install" thing may provide a patch for supporting this. I can put this on my list of open points as well, or we may ask Kai Backmann (are you listening?) to put this on his build environment revision project. - 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. And I want Linux to be successful in both (or more) worlds as well. Not sure about what you say, but in any case doing both ways does not hurt... ;-). Agreed. Thanks for your explanations and comments, I am enjoying the discussions ... :-) "me too" ;-) Thanks for your openess. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
-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
Re: [dev] Packaging process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Lohmaier wrote: > That is as getting all your software from Microsoft, one single > "Distributor". This comparison is shit. > But on windows you can basically get every software from any vendor. If > it is labeled "runs on windows XP", you can be pretty sure that it runs > (despite the bugs it might have). Just because they either are statically linked or ship every lib they need because of the DLL-hell. wow. > Now try to apply this to linux distributions. Get a package for SuSE and > try to install that on Redhat. At best you can use --nodeps to ignore > the different naming-schemes of the packages and it will run. > But using switches to bypass deps or other things surely is not the best > way on how a package management tool should work. Well, your problem if you try to do that... > The situation gets worse with older installations. There is no "linux > version X" label you could specify. It most likely is "You need version > X of glibc" (that is the reason why I cannot use most of the precompiled > stuff that is offered, my version is just too old), "furthermore you Which ancient stuff do you use? In any case, yes, then you need either build it yourself or upgrade. (Or install the new lib, which arguably in case of libc is not a good idea) > need $foo and $bar". $foo and $bar themselves require other packages or > worse conflict with other packages. (think of sound-severs, > desktop-environments,) Sounds like a bug to me if packages for GNOME e.g. conflict against KDE... Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoREi+FmQsCSK63MRAqJYAJ9ums4YCTi+z64xIm6zattmDP9WcgCfZkiV feYGOAiQtwRzNbSLoYHAmCc= =iaHN -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
2006/6/27, Éric Bischoff <[EMAIL PROTECTED]>:
Le Mardi 27 Juin 2006 10:10, Janne Johansson a écrit:
> > Any package maintainer listening here to confirm or denegate what I am
> > saying ? I used to work in a linux distribution, so I think I can
express
> > opinions on this topic, but some package maintainers might see that
> > differently.
>
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is
> meant to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.
>
> If not for those reasons, then for the reason that zillions of other
> opensource products happen
> to have a "unpack ; configure ; make ; make install" routine well built
in
> into the spines of us builders.
For which distro are you facing those problems?
We have a multiplatform packaging system (though I dont expect OOo2 to
build for anything else than linux-x86) called "buildit" which is a
collection
of shellscripts that automate the above procedure (unpack, conf...) and does
some dependency handling. It's very small, internal for us, but seems to
work
for the majority of normal apps that obey configure
--prefix=/somewhere/else.
Also, we are running our linuces on a small system for which we dont pull in
any
(except X11) dist-apps, but rather keep our own apps in versioned
directories
(like /pkg/tcsh/6.14.00/bin/tcsh) so we can keep parallell instances next to
each
other. This may or may not be the silliest idea since sliced bread but it
does
make it very visible which projects are relocatable "easily" and which want
everything
under /usr/{bin/lib/share}. OOo2 strikes me as a "you should have stuffed it
all
in one place because it breaks otherwise" when working on it.
There are so many points where the "unstandard" build style of OOo hits me.
Our build system naievely assumes "unpack ; patch ; prep (configure) ; build
; install"
works, but since OOo2 does unpack stuff after configure is run and don't
seem to
propagate configure-stuff to the newly unpacked configures, I seem to loose
out
on stuff. (libxmlsec gets a --without-openssl even though I gave the
toplevel an openssl
argument; pyuno gets a PYTHON_CFLAGS with -I/my/path/include but not a
PYTHON_LIBS with -L/my/path/lib)
And to actually get somewhere back to the original Q about the "dev" (or in
my case builder)
experience, I feel like it does copy lots of gifs and does zip magic on
dpzz's lots and lots
early on, making the turnaround times for figuring out which flags dont work
take a long while.
For me.
I've also found out "dmake -P3" makes it go "sleep 1" in a lot of subdirs
between builds.
--
Some mornings, it's just not worth gnawing through the straps...
Re: [dev] Packaging process
Hi *, On Tue, Jun 27, 2006 at 01:02:58PM +0200, Rene Engelhard wrote: > > [ 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 ] You shouldn't have made it polite, but instead should have tried to focus on the topic itself. (note that the thread is labeled with "packaging process"...) > Kay Ramme - Sun Germany - Hamburg wrote: > > 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. All this is independent of the packaging. > And you don't build some of the optional stuff. > You have various UNFIXED security things open (Mozilla to name the most > prominent one). This is not either. If not building some optional stuff breaks the default packaging, then it would be a bug. > In any case, it is a no-no for a Linux distri to ship binaries you just > got. Nobody questioned that. > [...] > > >... 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. The problem is not that you cannot determine what version is installed, but that often libraries are not compatible. Versions compiled with version $foo doesn't run on version $bar > [...] ciao Christian -- NP: Silverchair - Shade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Rene, On Tue, Jun 27, 2006 at 01:06:10PM +0200, Rene Engelhard wrote: > Christian Lohmaier wrote: > > That is as getting all your software from Microsoft, one single > > "Distributor". > > This comparison is shit. Starts great. > > But on windows you can basically get every software from any vendor. If > > it is labeled "runs on windows XP", you can be pretty sure that it runs > > (despite the bugs it might have). > > Just because they either are statically linked or ship every lib > they need because of the DLL-hell. wow. That doesn't matter. > > Now try to apply this to linux distributions. Get a package for SuSE and > > try to install that on Redhat. At best you can use --nodeps to ignore > > the different naming-schemes of the packages and it will run. > > But using switches to bypass deps or other things surely is not the best > > way on how a package management tool should work. > > Well, your problem if you try to do that... Hello? May I remind you of what this side-part of the discussion is about? > [...] > > need $foo and $bar". $foo and $bar themselves require other packages or > > worse conflict with other packages. (think of sound-severs, > > desktop-environments,) > > Sounds like a bug to me if packages for GNOME e.g. conflict against > KDE... Yeah - the old "pick *parts* of a statement and make whitty comments about it" tactic. The desktop-environments was related to the need $foo that in turn requires another part, not on the conflicts one. ciao Christian -- NP: Silverchair - Shade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Am Dienstag, 27. Juni 2006 13:56 schrieb Christian Lohmaier: > You shouldn't have made it polite, but instead should have tried to > focus on the topic itself. (note that the thread is labeled with "packaging > process"...) And it already drifted away a bit. > > In any case, it is a no-no for a Linux distri to ship binaries you just > > got. > > Nobody questioned that. Then I read Kays comments wrong... But he said stuff about "we fix it so than you can take our rpms"... > > 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. > > The problem is not that you cannot determine what version is installed, > but that often libraries are not compatible. Versions compiled with > version $foo doesn't run on version $bar That's what SONAMEs are for (barring library bugs which often are quite fast fixed after they have been found in Debian unstable (or by users by other distris who installed libs themselved) because other distris rebuild everything on a node library update) and therefore don't find it.)). In your case, the SONAME just should bump. Of course, if you build against a newer lib, due to ELF linking it might not run against a older one (because just functions/symbols got added which don't warrant a SONAME bump) this might be right. But for that you have a build environment with that old lib and you have a reliable one. That's what Sun is doing now anyway with their glibc etc baseline. So that's no argument for including every lib in the tree. 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]
Re: [dev] Packaging process
On Tue, Jun 27, 2006 at 11:09:39AM +0200, Éric Bischoff wrote: > Le Lundi 26 Juin 2006 21:33, Christian Lohmaier a écrit : > > ? The user doesn't have to bother. Either they use the packages provided > > by $distribution or they take the packages from vanilla OOo. > > > > And the packagers who are doing the packages for their distribution > > should know how to unpack something or how to compile from source. > > > > I absolutely do not get your point. > > My point is : why make it unnatural and complicated when you can do it in the > normal, regular way? The normal, regular way is to package software that > installs with "make install". Because the structure of the OOo build-process is anything but regular, normal way? > Currently, if distributions want to do serious changes in OOo, they have to > learn the whole build mechanism, scp2 bits, etc, to finally build a package > that they will disassemble right away. Of course they can learn how to do > that, it's just unusual, since no other software than OOo goes that way. Yes. scp2 is special. But again: This has nothing to do about whether to do a make install or to not. > > You can use linkoo to create an installation out of your build-dir. > > I did not know that. So that would be equivalent to a "make install"? Where > is > that documented? There is some minimalistic info in the Hacking-guide in the wiki. > > > I install my distribution, and all software works smoothly together. > > > > That is as getting all your software from Microsoft, one single > > "Distributor". > > Okay, that piece of discussion is unrelated to main topic. It is even > completly off-topic ;-) but interesting, so let's continue with that. > Perharps in private if it bothers the others. > > Yes, you are right. That's like getting all your software from Microsoft. But > there are a few differences that make a lot of importance (caution, troll > included): > > 1) In fact, many companies _do_ get all their software from Microsoft, > putting > themselves in a state of strategic dependancy. I was not talking about companies, but end-users. And yes, if they get everything from microsoft, they're using a distribution and thus is a subset not related to the point. > 2) The software in your Linux distribution has not been written by the > distributor... Again this is not the point. A distributor's job is to ensure interoperability between the software packages it provides. In windows world the only thing that you can count to a similar framework may be the driver certification that almost no (low-end) vendor uses. But this is more hardware related stuff and thus unrelated again. > 3) You have the choice of your distributor. There's real concurrence. Again true, but totally missing the point. The point was: "Get binary from $vendor and run it without problems" is possible with windows, but not with linux. With linux you have: "Get the version built for Redhat if you're using RedHat", "get the version built for SuSE if you'Re using SuSE". "If you're using another distribution, then we can not guarantee that it will work - you can try one of the other distribution-packages or compile yourself. Good luck" > 4) A Linux distribution contains almost all the software you might need, it's > seldom needed to look outside of your distro. Again missing the point. I don't deny that. > 5) With Microsoft you cannot adapt the software to your needs. You have not > the source. Again true but missing the point. > > Now try to apply this to linux distributions. Get a package for SuSE and > > try to install that on Redhat. > > No one does that. Software is coherent within ONE distribution. Here you have the point (although you didn't realize that this was the point). > Listen, that's two different approaches. Why not just admit that it's > different philosophies, with both their advantages and drawbacks? I did not deny that, and the different philosophies don't matter at all. > And, returning to main topic, why try to import into Linux a packaging > philosophy that is adapted to Windows? Because unless most of the linux or the windows software, OOo is a cross-platform thing that existed for years. As with mozilla/firefox there are binary packages for the different operating systems/distros. OOo always worked like that. And why don't you want users to be able to install the vanilla version, but instead trying to "force" them use the version from their distribution? ciao Christian -- NP: Silverchair - Shade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
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 think
Re: [dev] Packaging process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kay Ramme - Sun Germany - Hamburg wrote: [...] What I wanted to say with the introduction was that I tried to be polite but as there was things you mentioned which are no-no for distributions and you offended all Debian users I needed to make clear I try that but I cannot gurantee it. I wrote that mail in one go. [...] > >>>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. We can't always. Release schedules is release schedules. For example, we freeze in October, new OOo will come September. I am not sure we will have enough time to get it into the distri. (Building, testing in real-world, all library dependencies must be met etc, various revisions, approval cycles, etc) Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I maybe could have gotten that in, but 1.1.3 needed updates first and then it was too late. 1.1.5 was released *after* the sarge release) > >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? No. Not for old versions. Just new versions. And the OOo tree still contains mozilla 1.7.5 which you build against (NB: I don't know how your build env looks like) and ship. > >In any case, it is a no-no for a Linux distri to ship binaries you just > >got. > For what reason? Because you can't do source fixes? You can't produce reliable binaries? You can't provide packages for other archs (like we also do ppc and sparc, for 1.1.x there also was s390) > >And not everything is configurable... > So you patch what is not configurable? And what we need for other stuff, too. We also of course patch the configs for our default-configs. We also patch features in if that's sensible or if those features are planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc) after all, OOo claims to be free software, so changing it is allowed (claims to becausse there's stuff which is *not* free in the tree since loong which outstanding issues for them...) > >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? Right. > >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. Yeah, I know, but you implied wanting every distri getting the rpms from OOo and building their rpms/debs out of that. > >>>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? When I can fix them I submit fixes as well. But they also didn't get applied See for example http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy fix (ABI change, though, anyway) so it's not a that good example but it was possible to fix with some coordination for a major release like 2.0. I mostly commit fixes myself now when I have some... When I can not there's problems.. But for important functionality bugs or licensing bugs there's still no fix. Issue numbers on request...
Re: [dev] Packaging process
Le Mardi 27 Juin 2006 14:14, Christian Lohmaier a écrit : > > I did not know that. So that would be equivalent to a "make install"? > > Where is that documented? > > There is some minimalistic info in the Hacking-guide in the wiki. OK. Minimalistic info in some hackers guide. On the other hand, "make install" is something well documented and well known. > > And, returning to main topic, why try to import into Linux a packaging > > philosophy that is adapted to Windows? > > Because unless most of the linux or the windows software, OOo is a > cross-platform thing that existed for years. That's historical reasons. > As with mozilla/firefox there are binary packages for the different > operating systems/distros. OOo always worked like that. These are indeed interesting to the end users, not to the developpers nor the packagers. > And why don't you want users to be able to install the vanilla version, > but instead trying to "force" them use the version from their > distribution? I fully agree users should be able to choose. No one is forced to do anything. The only thing his, when they use the distribution version, they have more guarantee about coherence with other software, adequacy with the general philosophy of the distribution, conformance to the security policy, etc. That's why it makes usually a better choice for the John Doe user to choose the version packaged with his distribution. -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Rene, Rene Engelhard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kay Ramme - Sun Germany - Hamburg wrote: [...] What I wanted to say with the introduction was that I tried to be polite but as there was things you mentioned which are no-no for distributions and you offended all Debian users I needed to make clear I try that but I did _not_ offend any Debian user, I am only asking questions and making suggestions and express my opinion. For example, what is wrong about asking why distros always compile everything by their own? It may be naive but in _no_ terms offensive! I cannot gurantee it. I wrote that mail in one go. So, I suggest that you reread your mails before pushing the send button. I do not have any tolerance for lazy mails (while I do not say that your mails were lazy so). [...] 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. We can't always. Release schedules is release schedules. For example, we freeze in October, new OOo will come September. I am not sure we will have enough time to get it into the distri. (Building, testing in real-world, all library dependencies must be met etc, various revisions, approval cycles, etc) So, if you think that you do not have enough time to import the latest OOo or that it does not match your quality guide lines, I suggest to either go with the old one, or to officially raise your voice and to express your concerns. I am pretty sure Martin is listening and would escalate any issue as needed and appropriate. Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I maybe could have gotten that in, but 1.1.3 needed updates first and then it was too late. 1.1.5 was released *after* the sarge release) So, 1.1.3 seems to be reasonable than. 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? No. Not for old versions. Just new versions. And the OOo tree still So, what are they saying that they do not update the older versions? Are they backporting the fixes, or is Debian doing that? contains mozilla 1.7.5 which you build against (NB: I don't know how your build env looks like) and ship. As already said elsewhere, the problem is, that we did not find a way, to reliable express dependencies against 3rd party stuff, except for the real core stuff, as libc and friends. And AFAIK even these are not expressed in a formally correct way. In any case, it is a no-no for a Linux distri to ship binaries you just got. For what reason? Because you can't do source fixes? You can't produce reliable binaries? You certainly can, every binary release of OOo is (nearly:-) bitwise reproduceable and tagged accordingly in CVS. And I would be surprised, if our binaries would be less stable than yours ... You can't provide packages for other archs (like we also do ppc and sparc, for 1.1.x there also was s390) You may want to look at this from the other side. Builds for other archs may very well just be contributions to OpenOffice.org. OpenOffice.org would than obviously provide these contributions. There is no need to rebuild anything, even if you want to support other archs. And not everything is configurable... So you patch what is not configurable? And what we need for other stuff, too. We also of course patch the configs for our default-configs. We also patch features in if that's sensible or if those features are planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc) What about providing patches to configure the needed things at run- or deployment-time? after all, OOo claims to be free software, so changing it is allowed It certainly is, and, if I understand correctly (so, please correct me if I am wrong), you are basically maintaining a fork! (claims to becausse there's stuff which is *not* free in the tree since loong which outstanding issues for them...) You may want to give me a hint? Yeah, I know, but you implied wanting every distri getting the rpms from OOo and building their rpms/debs out of that. No, you misunderstood me. My
Re: [dev] Packaging process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Kay Ramme - Sun Germany - Hamburg wrote: > >I cannot gurantee it. I wrote that mail in one go. > So, I suggest that you reread your mails before pushing the send button. > I do not have any tolerance for lazy mails (while I do not say that your > mails were lazy so). I already did two times. Anyway, sorry. > >>>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? > > > >No. Not for old versions. Just new versions. And the OOo tree still > So, what are they saying that they do not update the older versions? Are > they backporting the fixes, or is Debian doing that? There are not. There wasn't really firefox security updates except new firefox releases with other stuff. Same with the "normal" Mozilla. > >contains mozilla 1.7.5 which you build against (NB: I don't know how > >your build env looks like) and ship. > As already said elsewhere, the problem is, that we did not find a way, > to reliable express dependencies against 3rd party stuff, except for the > real core stuff, as libc and friends. And AFAIK even these are not You also ship getopt and readdir. Which reminds me I need to finish my patch to hack that out and make Linux builds not use it. > expressed in a formally correct way. Yes, but then you still could have updated mozilla in-tree. it's still 1.7.5 there. Also the handling of issue http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad. > >Because you can't do source fixes? You can't produce reliable binaries? > You certainly can, every binary release of OOo is (nearly:-) bitwise > reproduceable and tagged accordingly in CVS. And I would be surprised, > if our binaries would be less stable than yours ... No, you only can (assuming you take the binaries) when you got a new release. (Or a new milestone, rc, whatever, where the first is not really recommended for a stable release and the rc, well, it might, but..) > >You can't provide packages for other archs (like we also do ppc and > >sparc, for 1.1.x there also was s390) > You may want to look at this from the other side. Builds for other archs > may very well just be contributions to OpenOffice.org. OpenOffice.org > would than obviously provide these contributions. There is no need to > rebuild anything, even if you want to support other archs. Oh? You do e.g. Linux SPARC builds/porting? Where? Last I know only Jim Watson does. You surely own sparcs at Sun so hardware cannot be the issue? Analog with Linux/powerpc. > >after all, OOo claims to be free software, so changing it is allowed > It certainly is, and, if I understand correctly (so, please correct me > if I am wrong), you are basically maintaining a fork! No. A fork is if you fork off a codebase and do own stuff. This is some adaptions and eventually a few features which will get upstream. This is *not* a fork. > >(claims to becausse there's stuff which is *not* free in the tree since > >loong which outstanding issues for them...) > You may want to give me a hint? http://qa.openoffice.org/issues/show_bug.cgi?id=21678 http://qa.openoffice.org/issues/show_bug.cgi?id=37034 - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) - - questionable licenses for the hyphs (need to remove all but de and hu) - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) - - jurt/doc - - netbeans_integration, I am quite sure there's stuff non-free/not LGPL compatible, correct me if not For those issues I didn't file an issue because it woldn't have brought anything (see the jars issue). But we nevertheless need to remove this stuff from Debians source and binaries. > >>Are you only submitting bugs or fixes as well? > > > >When I can fix them I submit fixes as well. > >But they also didn't get applied See for example > >http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy > >fix (ABI change, though, anyway) so it's not a that good example but > >it was possible to fix with some coordination for a major release like > >2.0. > I take a look at it Thanks, but it mostly was important for 1.1.x (although probably too big) or for 2.0 (best time for an ABI change). I don't think you want to change the ABI now, do you? > >I mostly commit fixes myself now when I have some... > Sounds good :-) > > > >When I can not there's problems.. But for important functionality bugs > >or licensing bugs there's still no fix. Issue numbers on request... > Just give me some ids, I try to comment ... See above. Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is still not fixed even with michaels patch, and so it's disabled completely in Debian...). Or that LFS issue above which had a tiny change (whic
Re: [dev] Packaging process
Hi Rene, Rene Engelhard wrote: Kay Ramme - Sun Germany - Hamburg wrote: (Not to mention you renamed the packages so that they are not parallel installable anymore with the official debs, but that's another matter) This is unfortunate. But, we can not really know and check all distros package names. yes, but there's only one Debian and you could have looked. In any case, I raised my voice hours after I saw that on the CVS list so there would be a chance to revert that (the wasn't something bad about openofficeorg-* instead of openoffice.org-*). But I agree it's only unfortunate... I still don't see the problem here: who - beside package maintainers - would want to install _released_ vanilla OOo beside debian OOo on a single system ? How many users actually complained about this ? For milestone builds, ooo-dev is used for package names. And I thought we worked out a way to avoid incompatible mixtures of the two package sources. What I agree with being unfortunate is that we started with "openofficeorg" initially. We somehow expected the '.' to cause problems, but the ure package proved the opposite. Regards, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Am Dienstag, 27. Juni 2006 13:58 schrieb Christian Lohmaier: > Hi Rene, > > On Tue, Jun 27, 2006 at 01:06:10PM +0200, Rene Engelhard wrote: > > Christian Lohmaier wrote: > > > That is as getting all your software from Microsoft, one single > > > "Distributor". > > > > This comparison is shit. > > Starts great. But is true. > > [...] > > > need $foo and $bar". $foo and $bar themselves require other packages or > > > worse conflict with other packages. (think of sound-severs, > > > desktop-environments,) > > > > Sounds like a bug to me if packages for GNOME e.g. conflict against > > KDE... > > Yeah - the old "pick *parts* of a statement and make whitty comments > about it" tactic. I don't see where I used that tactic. If stuff like that happens, it's a bug. > The desktop-environments was related to the need $foo that in turn > requires another part, not on the conflicts one. Ah, sure And you said about them conflicting against some desktop-environment. Please decide. Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 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]
Re: [dev] Packaging process
Rene, Rene Engelhard wrote: So, what are they saying that they do not update the older versions? Are they backporting the fixes, or is Debian doing that? There are not. There wasn't really firefox security updates except new firefox releases with other stuff. Same with the "normal" Mozilla. Does Mozilla describe somehow, how distros are supposed to bundle its applications and how they are supporting the distros or something similar? This obviously should include the handling of security patches etc. contains mozilla 1.7.5 which you build against (NB: I don't know how your build env looks like) and ship. As already said elsewhere, the problem is, that we did not find a way, to reliable express dependencies against 3rd party stuff, except for the real core stuff, as libc and friends. And AFAIK even these are not You also ship getopt and readdir. Which reminds me I need to finish my patch to hack that out and make Linux builds not use it. expressed in a formally correct way. Yes, but then you still could have updated mozilla in-tree. it's still 1.7.5 there. Also the handling of issue http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad. You are not shipping our version of Mozilla, so I would say, this is more or less our problem only. By the way, I think it would have been nice, to separate 3rd party stuff into their own packages (going to add this to my notes). Because you can't do source fixes? You can't produce reliable binaries? You certainly can, every binary release of OOo is (nearly:-) bitwise reproduceable and tagged accordingly in CVS. And I would be surprised, if our binaries would be less stable than yours ... No, you only can (assuming you take the binaries) when you got a new release. (Or a new milestone, rc, whatever, where the first is not really recommended for a stable release and the rc, well, it might, but..) I do not understand this, could you elaborate? You can't provide packages for other archs (like we also do ppc and sparc, for 1.1.x there also was s390) You may want to look at this from the other side. Builds for other archs may very well just be contributions to OpenOffice.org. OpenOffice.org would than obviously provide these contributions. There is no need to rebuild anything, even if you want to support other archs. Oh? You do e.g. Linux SPARC builds/porting? Where? Last I know only Jim Watson does. You surely own sparcs at Sun so hardware cannot be the issue? Analog with Linux/powerpc. I was talking about contributing. The work does not necessarily need to be done by us. In my opinion, this all is only a question of scalability. Things need to be done where they belong. Installation sets etc. IMHO belong to the project, they may very well be contributed by others, so. I would love to be able to put mozilla.org, x.org, openoffice.org, gnome.org etc. into my sources.list and to dynamically and _directly_ update my Linux. (claims to becausse there's stuff which is *not* free in the tree since loong which outstanding issues for them...) You may want to give me a hint? http://qa.openoffice.org/issues/show_bug.cgi?id=21678 This was some reading, I think I understand the issue and expect Martin to fix it for 2.0.4. 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. - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) This is indeed ugly. Could basegfxs replace gpc completely? - - questionable licenses for the hyphs (need to remove all but de and hu) - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) Need to take a look ... - - jurt/doc This is ridiculous, somebody should just remove it! For those issues I didn't file an issue because it woldn't have brought anything (see the jars issue). But we nevertheless need to remove this stuff from Debians source and binaries. We may want to discuss these things further on OOoCon2006. May be together with other distributions. I mostly commit fixes myself now when I have some... Sounds good :-) When I can not there's problems.. But for important functionality bugs or licensing bugs there's still no fix. Issue numbers on request... Just give me some ids, I try to comment ... See above. Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is still not fixed even with michaels patch, and so it's disabled This seems to be a distro issue only, so I am not sure why the patch did not make it yet. completely in Debian...). Or that LFS issue above which had a tiny change (which changed ABI, though, I am aware, so I didn't force it into my packages myself, although I think it wouldn't have mattered, we use an other stlport than you anyway - http://packages.debian.org/libstlport4.6) If I understand
Re: [dev] Packaging process
Hi, Am Mittwoch, 28. Juni 2006 10:52 schrieb Kay Ramme - Sun Germany - Hamburg: > Rene Engelhard wrote: > > Yes, but then you still could have updated mozilla in-tree. it's still > > 1.7.5 there. Also the handling of issue > > http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad. > You are not shipping our version of Mozilla, so I would say, this is > more or less our problem only. We are going to ship no version of Mozilla... > > 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 we also not allowed to ship non-free stuff. And it doesn't do users good to omit that Guide... > > - - using non-free libraries like gpc > > (thankfully now avoidable by --disable-gpc and using basegfxs stuff) > This is indeed ugly. Could basegfxs replace gpc completely? 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... > > - - questionable licenses for the hyphs (need to remove all but de and hu) > > > > - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) > Need to take a look ... > > > - - jurt/doc > This is ridiculous, somebody should just remove it! Maybe, but it's there.. > > See above. > > Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is > > still not fixed even with michaels patch, and so it's disabled > This seems to be a distro issue only, so I am not sure why the patch did > not make it yet. 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. > > completely in Debian...). Or that LFS issue above which had a tiny > > change (which changed ABI, though, I am aware, so I didn't force it into > > my packages myself, although I think it wouldn't have mattered, we use > > an other stlport than you anyway - > > http://packages.debian.org/libstlport4.6) > If I understand correctly, LFS is at least not incompatible UNO wise. I > do not know yet if it has any influence on the base line, but if it has > not, there should be no problem to just enable it. It seems even to be a > very local change (SAL). well, it changes ABI... > > 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. > 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.. > > currently > > Or for bugfixes which can't be done because the OOo build env doesn't > > support > > conditionalizing them... (Java has no #ifdefs for example), and some > So, go and fix it and send in the patches. Uh, you don't understand me. There's no conditionalizing possible because Java has no #ifedf like thing > > 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) > 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 y
Re: [dev] Packaging process
Hi Rene, On Tue, Jun 27, 2006 at 02:20:18PM +0200, Rene Engelhard wrote: > Am Dienstag, 27. Juni 2006 13:58 schrieb Christian Lohmaier: > > On Tue, Jun 27, 2006 at 01:06:10PM +0200, Rene Engelhard wrote: > > > Christian Lohmaier wrote: > > > > That is as getting all your software from Microsoft, one single > > > > "Distributor". > > > > > > This comparison is shit. > > > > Starts great. > > But is true. "Immer zweimal mehr wie Du"... If you'd explain why this "comparison is shit", then I might explain better. If it is just because I used "Microsoft" there and not "Random Company that sells you windows bundled with additional software" - then I cannot help you. > > > [...] > > > > need $foo and $bar". $foo and $bar themselves require other packages or ^^ > > > > worse conflict with other packages. (think of sound-severs, > > > > desktop-environments,) > > > > > > Sounds like a bug to me if packages for GNOME e.g. conflict against > > > KDE... > > > > Yeah - the old "pick *parts* of a statement and make whitty comments > > about it" tactic. > > I don't see where I used that tactic. If stuff like that happens, it's a bug. Yes. It is a bug. But that wasn't implied by my posting. The tactic is that picking things to direct the discussion away from the topic, away from the statement that the parent poster made. I just highlighted the important "or" for you. But still: The bugs or the fact that a package management tool can resolve these problems *when using packages for the same distro* is /not/ what I was talking about. > > > The desktop-environments was related to the need $foo that in turn > > requires another part, not on the conflicts one. > > Ah, sure And you said about them conflicting against some > desktop-environment. > Please decide. That is bullshit to say it with your words. Read again. And don't miss the "or" this time. ciao Christian -- NP: Papa Roach - Between Angels And Insects - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]> writes: >> - - using non-free libraries like gpc >> (thankfully now avoidable by --disable-gpc and using basegfxs stuff) > This is indeed ugly. Could basegfxs replace gpc completely? > This is mostly a question of test coverage. Functionality-wise, it's clearly possible. Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Thorsten, Thorsten Behrens wrote: Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]> writes: - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) This is indeed ugly. Could basegfxs replace gpc completely? This is mostly a question of test coverage. Functionality-wise, it's You mean, we do not know what we may break, do we? clearly possible. Would it be reasonable to do it in one of the next updates? Cheers, Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
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? 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? - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) This is indeed ugly. Could basegfxs replace gpc completely? 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? - - questionable licenses for the hyphs (need to remove all but de and hu) - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) Need to take a look ... - - 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. See above. Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is still not fixed even with michaels patch, and so it's disabled This seems to be a distro issue only, so I am not sure why the patch did not make it yet. 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. completely in Debian...). Or that LFS issue above which had a tiny change (which changed ABI, though, I am aware, so I didn't force it into my packages myself, although I think it wouldn't have mattered, we use an other stlport than you anyway - http://packages.debian.org/libstlport4.6) If I understand correctly, LFS is at least not incompatible UNO wise. I do not know yet if it has any influence on the base line, but if it has not, there should be no problem to just enable it. It seems even to be a very local change (SAL). 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. 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? 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? currently Or for bugfixes which can't be done because the OOo build env doesn't support conditionalizing them... (Java has no #ifdefs for example), and some So, go and fix it and send in the patches. Uh, you don't understand me. There's no conditionalizing possible because Java has no #ifedf like thing #ifdefs are often the wrong approach anyway. Find a patch which generalizes the code. Also, it would be nice to concretely see the problem you
Re: [dev] Packaging process
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 m
Re: [dev] Packaging process
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
Re: [dev] Packaging process
Am Donnerstag, 29. Juni 2006 15:34 schrieb Kay Ramme - Sun Germany - Hamburg: > > 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 Is is. Of course, those different versions have differend SONAMEs. > 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. Yes.. ALthough db4.2 is that old But there unfortunately are distros which think they always must port stuff to the newest db and drop the old ones with no reasons (ok, for db4.2 there is because it has some licensing problems) > > 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! There already is --with-system-zlib. Just not enabled per default for everyone because *you* (Sun) didn't want that. I am for enabling it on all Linux build from the start. getopt is libc, so getopt is out of the discussion to make optional, and my upcoming patch will make it unconditional. Did yet have to do other stuff... Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 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]
Re: [dev] Packaging process
Rene, that was a fast reply :-) Rene Engelhard wrote: Am Donnerstag, 29. Juni 2006 15:34 schrieb Kay Ramme - Sun Germany - Hamburg: 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 Is is. Of course, those different versions have differend SONAMEs. So, if it has nothing to do with SONAMEs, why did you talk about SONAMES in the first place? 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. Yes.. ALthough db4.2 is that old But there unfortunately are distros which think they always must port stuff to the newest db and drop the old ones with no reasons (ok, for db4.2 there is because it has some licensing problems) So, you agree that there is no solution as to bring it privately with us? Also, this is what LSB recommends for non LSB stuff. There already is --with-system-zlib. Just not enabled per default for everyone because *you* (Sun) didn't want that. I am for enabling it on all Linux build from the start. There must be a reason for disabling it by default. If there is not, nobody would hinder you to turn it on. getopt is libc, so getopt is out of the discussion to make optional, and my upcoming patch will make it unconditional. Did yet have to do other stuff... See above. Regards, Rene Rene, you still did not provide any real reason to build the stuff by your own, instead of contributing and improving the overall situation for all (Debian based) distributions and users. The technical reasons you listed were IMHO _all_ minor. This is _not_ to offend you in any way, I certainly appreciate your work! I certainly can accept, that you say, that "this is what distros do", and I am willing to support you! But, I still think that this is wrong technical approach and I am going to keep my opinion until somebody argues the opposite in a way, that I can understand. Thanks for the discussions and looking forward to meeting you at the OOoCon2006 Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Kay Ramme - Sun Germany - Hamburg wrote: 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? we are currently evaluating if we can open source the guide. But i would say the guide is free, because it is free available, people can extend or correct the content and Sun is only maintaining the guide because a ~1200 pages document needs to be maintained in a structured way. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Am Donnerstag, 29. Juni 2006 17:36 schrieb Jürgen Schmidt: > Kay Ramme - Sun Germany - Hamburg wrote: > > 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? > > we are currently evaluating if we can open source the guide. But i would > say the guide is free, because it is free available, people can extend Wrong. > or correct the content and Sun is only maintaining the guide because a Wrong. Read your own license statement again. "This document is distributed under licenses restricting its use. You may make copies of and redistribute it, but you may not modify or make derivative works of this documentation without prior written authorization of Sun and its licensors, if any. Copyright 2005 Sun Microsystens, Inc." -> no allowance to modify and redistribute modified works -> not free 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]
Re: [dev] Packaging process
Juergen, Jürgen Schmidt wrote: we are currently evaluating if we can open source the guide. But i would Can we help somehow? Juergen Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Kay Ramme - Sun Germany - Hamburg wrote: Juergen, Jürgen Schmidt wrote: we are currently evaluating if we can open source the guide. But i would Can we help somehow? mmh not sure if you can help at the moment. That we will open source the guide is as likely as not (everything else would be surprising for me). But we currently evaluating the format. The guide was transformed into solbook which is a docbook derivate and used inside Sun's documentation department. The documentation department prefer docbook as source format to make use of a lot of existing tools to work with the format. Docbook is established as the preferred format for documentation in the open source world. On the other side we have our Open Document Format and the office would be the best tool to work on the docu but there are some disadvantages (i think most of them are post processing issues, i will provide more info asap) compared to docbook. Our docbook filter hasn't the quality to use it in production, maybe some volunteers are interested and like to work on improvements of the filter. I am personal are flexible but i don't want to loose the support of Sun's documentation department which of course can be a big help to create a professional guide. We also thought about a transformation into the wiki but it is not yet clear how we can extract the relevant info from the wiki to prepare a usable guide (e.g. PDF) as we can it currently. Although a wiki would have some advantages we currently prefer a different format. Maybe you have some further ideas what would be the best way to maintain and work with such a huge document. Splitting in smaller parts is already planned ;-) (DevGuide 1-5 or something like that) But that wouldn't change the problem because even the split parts of the guide are parts of one big project. Juergen Juergen Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Juergen Our docbook filter hasn't the quality to use it in production, maybe some volunteers are interested and like to work on improvements of the filter. We at inDesko wroked on ooo2dbk framework, i announced last year you may find here in french for the most up to date version http://www.indesko.com/sites/fr/telechargements/ooo2dbk/view (the svn contains english too and much uptodate iirc) i give the english link too http://www.indesko.com/sites/en/downloads/ooo2dbk/view (the svn adress is not up todate - sorry) we are actually working at spare time on the opendocument support (well, i bit staleld at this moment) the project would be boosted if we find customers but i think this is a basis - Obviously this is free software :-) I am personal are flexible but i don't want to loose the support of Sun's documentation department which of course can be a big help to create a professional guide. sure ! We also thought about a transformation into the wiki but it is not yet clear how we can extract the relevant info from the wiki to prepare a usable guide (e.g. PDF) as we can it currently. Although a wiki would have some advantages we currently prefer a different format. a wiki would be cool yes and is setup for collaboration work retreiving the content is quite easy i think (but i've never done) Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Jürgen, Jürgen Schmidt wrote: We also thought about a transformation into the wiki but it is not yet clear how we can extract the relevant info from the wiki to prepare a usable guide (e.g. PDF) as we can it currently. Although a wiki would have some advantages we currently prefer a different format. I am all for the wiki approach. The wiki allows to split the content according to the projects. It scales, is designed to be very simple to use as well as it is offering a place for discussion. On the other hand, I am certainly no expert in professional writing at all. Maybe you have some further ideas what would be the best way to maintain and work with such a huge document. Splitting in smaller parts is already planned ;-) (DevGuide 1-5 or something like that) But that wouldn't change the problem because even the split parts of the guide are parts of one big project. The pure size is IMHO the biggest problem, I suggest to split it into pieces according to the established OOo projects. This is the only way I can think of, to get it scaling. Juergen Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Laurent Godard wrote: Hi Juergen Our docbook filter hasn't the quality to use it in production, maybe some volunteers are interested and like to work on improvements of the filter. We at inDesko wroked on ooo2dbk framework, i announced last year you may find here in french for the most up to date version http://www.indesko.com/sites/fr/telechargements/ooo2dbk/view (the svn contains english too and much uptodate iirc) i give the english link too http://www.indesko.com/sites/en/downloads/ooo2dbk/view (the svn adress is not up todate - sorry) we are actually working at spare time on the opendocument support (well, i bit staleld at this moment) the project would be boosted if we find customers but i think this is a basis - Obviously this is free software :-) I am personal are flexible but i don't want to loose the support of Sun's documentation department which of course can be a big help to create a professional guide. sure ! We also thought about a transformation into the wiki but it is not yet clear how we can extract the relevant info from the wiki to prepare a usable guide (e.g. PDF) as we can it currently. Although a wiki would have some advantages we currently prefer a different format. a wiki would be cool yes and is setup for collaboration work retreiving the content is quite easy i think (but i've never done) saying it's "easy" is easy ;-), i know that it is possible to extract data and create for example a PDF. But the output isn't comparable to what we have at the moment. Show me a working and satisfying solution and we can discuss it. Juergen Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi, saying it's "easy" is easy ;-), i know that it is possible to extract data and create for example a PDF. But the output isn't comparable to what we have at the moment. Show me a working and satisfying solution and we can discuss it. Juergen, you know such a solution is not yet set up and i think anything won't be done until a decision is made about freeing this document i said "easy", well, replace by doable provided we can work on the content and have the I/O specification of the document Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]> writes: > Thorsten Behrens wrote: >> Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]> writes: >> - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) >>> This is indeed ugly. Could basegfxs replace gpc completely? >>> >> This is mostly a question of test coverage. Functionality-wise, it's >> > You mean, we do not know what we may break, do we? > >> clearly possible. >> > Would it be reasonable to do it in one of the next updates? > It's easily possible, no problem - but what would that (in isolation) buy us? After all, it's configurable anyway... Shouldn't we turn the switch just after all the other roadblocks (for a unified OOo build) are out of the way? Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Laurent Godard wrote: Hi, saying it's "easy" is easy ;-), i know that it is possible to extract data and create for example a PDF. But the output isn't comparable to what we have at the moment. Show me a working and satisfying solution and we can discuss it. Juergen, you know such a solution is not yet set up and i think anything won't be done until a decision is made about freeing this document a working solution will probably have influence on the decision. We talk here about a huge project and we don't make a decision based on some gut feeling. Juergen i said "easy", well, replace by doable provided we can work on the content and have the I/O specification of the document Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Jurgen a working solution will probably have influence on the decision. We talk here about a huge project and we don't make a decision based on some gut feeling. sure !! but you may admit that the problem is a 'cricular reference' :-) Btw, i may find some volunteers setting up a prototype but i may need the desired output format Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] DevGuide license (was: Re: [dev] Packaging process)
Am Donnerstag, 29. Juni 2006 17:36 schrieb Jürgen Schmidt: > Kay Ramme - Sun Germany - Hamburg wrote: > > 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? > > we are currently evaluating if we can open source the guide. But i would > say the guide is free, because it is free available, people can extend Wrong. > or correct the content and Sun is only maintaining the guide because a Wrong. Read your own license statement again. "This document is distributed under licenses restricting its use. You may make copies of and redistribute it, but you may not modify or make derivative works of this documentation without prior written authorization of Sun and its licensors, if any. Copyright 2005 Sun Microsystens, Inc." -> no allowance to modify and redistribute modified works -> not free Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 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]
[dev] Doc format (Was: Re: [dev] Packaging process)
Le Vendredi 30 Juin 2006 09:29, Jürgen Schmidt a écrit : > mmh not sure if you can help at the moment. That we will open source the > guide is as likely as not (everything else would be surprising for me). > But we currently evaluating the format. The guide was transformed into > solbook which is a docbook derivate and used inside Sun's documentation > department. The documentation department prefer docbook as source format > to make use of a lot of existing tools to work with the format. Docbook > is established as the preferred format for documentation in the open > source world. On the other side we have our Open Document Format and the > office would be the best tool to work on the docu but there are some > disadvantages (i think most of them are post processing issues, i will > provide more info asap) compared to docbook. DocBook allows to concentrate on the semantics, while OOo focuses on the presentation. That makes DocBook a better format for documentation. You can derive presentation from semantics, not the contrary. Okay, using a lot of styles in OOo may help. But still, one has to keep that funbdamental difference in mind. Besides that, almost all Open Source projects now use DocBook. -- Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son or. (Donjon de Naheulbeuk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Éric Bischoff wrote: Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit : - OOo should not attempt to build its own packages, at least under Linux. Under Linux, that's the distributions' work! This problem is related to the "make install" one. In my opinion, OOo is showing the right approach here, it is IMHO unfortunate and a waste of time, that everybody patches and builds everything by its own, leading to small incompatibilities and bugs here and there ... Okay, we have diverging opinions on this point ;-). Professional answer :-), I think I had implicitly the hope that you might be able to explain to me the motivations of the distributions, to always rebuild, repackage and patch everything. I already talked to some guys about it, but did not get it. 1) I think it just makes the life of OOo package maintainers in the Linux distributions much harder. I suppose that they basically rpm-install the OOo packages, and then repackage them. Or some might have come with the idea of short-circuiting the build process just before the packages are made and then simulate a "make install". But, in the end, what is the difference between rpm-install and make install (despite that some products may not be able to de-install themselves)? Any package maintainer listening here to confirm or denegate what I am saying ? I used to work in a linux distribution, so I think I can express opinions on this topic, but some package maintainers might see that differently. AFAIK, the most prominent reasons for distributions to build OOo by their own are - to not include or have any dependencies on non-free software (e.g. Java), - to optimize install sets by removing included 3rd party packages (freetype, expat, etc.) - to patch it to be more compliant to the target distribution, - to change the look&feel, e.g. to replace some icons etc., or - to change target locations, e.g. to provide OOo as a bundled product. 2) What about the distros that are not "officially supported"? Debian, Slackware, ... AFAIK, Debian is officially supported, the LSB recommended way is, to provide RPMs and to use "alien" on Debian. 3) For us developpers, when we rebuild everything, it is really boring to wait until packages are built and then install them. That is fully agreed, builds certainly should be usable without the generation of packages or the need to install them! Also, when we do only local changes, guessing the correct "cp" instruction to install our software in OOo runtime tree is much harder than running a "make install". This is IMHO the same as above, builds (without packages) need to be directly executable! I think it's not the role of the software developpers to distribute the software, just like it's not the role of package maintainers to develop software. If they patch the code, normally they should contribute their patches back in IssueZilla. I tend to disagree here (see above :-), if all products / software would be provided as packages by their developers, there would be far less incompatibilities between the distributions, and one wouldn't need to wait until a particular distribution would provide the latest package of a particular product ... Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>: Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit: > > - OOo should not attempt to build its own packages, at least under Linux. > > Under Linux, that's the distributions' work! > > This problem is related to the "make install" one. > > In my opinion, OOo is showing the right approach here, it is IMHO > unfortunate and a waste of time, that everybody patches and builds > everything by its own, leading to small incompatibilities and bugs here > and there ... Okay, we have diverging opinions on this point ;-). 1) I think it just makes the life of OOo package maintainers in the Linux distributions much harder. I suppose that they basically rpm-install the OOo packages, and then repackage them. Or some might have come with the idea of short-circuiting the build process just before the packages are made and then simulate a "make install". Any package maintainer listening here to confirm or denegate what I am saying ? I used to work in a linux distribution, so I think I can express opinions on this topic, but some package maintainers might see that differently. I am trying to fit OOo2 into our sourcebuilding packaging system, and I agree with your point. Having to go over rpms feels "stupid" in a way where not everything is meant to end up at /usr/local or where linux isn't necessarily implying you use (and like) rpms. If not for those reasons, then for the reason that zillions of other opensource products happen to have a "unpack ; configure ; make ; make install" routine well built in into the spines of us builders. -- Some mornings, it's just not worth gnawing through the straps...
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Janne, Janne Johansson wrote: If not for those reasons, then for the reason that zillions of other opensource products happen to have a "unpack ; configure ; make ; make install" routine well built in into the spines of us builders. In general, it shouldn't be to hard to support the "classic" Linux approach as well. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Kay Ramme - Sun Germany - Hamburg wrote: > >1) I think it just makes the life of OOo package maintainers in the Linux > >distributions much harder. I suppose that they basically rpm-install the > >OOo packages, and then repackage them. Or some might have come with the > >idea of short-circuiting the build process just before the packages are > >made and then simulate a "make install". No, we added a simple installer mechanism upstream (Michael Meeks did, thankfully) > >Any package maintainer listening here to confirm or denegate what I am > >saying ? I used to work in a linux distribution, so I think I can express see above. > AFAIK, the most prominent reasons for distributions to build OOo by > their own are > - to not include or have any dependencies on non-free software (e.g. Java), > - to optimize install sets by removing included 3rd party packages > (freetype, expat, etc.) > - to patch it to be more compliant to the target distribution, > - to change the look&feel, e.g. to replace some icons etc., or > - to change target locations, e.g. to provide OOo as a bundled product. - - fix bugs not fixed upstream for whatever reason Exactly. > >2) What about the distros that are not "officially supported"? Debian, > >Slackware, ... > AFAIK, Debian is officially supported, the LSB recommended way is, to > provide RPMs and to use "alien" on Debian. ROTL. Not everything the LSB says makes sense. The OOo build system *has* support for building debs. Use this. > >I think it's not the role of the software developpers to distribute the > >software, just like it's not the role of package maintainers to develop > >software. If they patch the code, normally they should contribute their > >patches back in IssueZilla. > I tend to disagree here (see above :-), if all products / software would > be provided as packages by their developers, there would be far less > incompatibilities between the distributions, and one wouldn't need to Then you don't have experience with this. Sorry, but this is completely wrong, and in any case you can't then add fixes either. (see clophs post for example) > wait until a particular distribution would provide the latest package of > a particular product ... That's the distributions' issue. Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoRE7+FmQsCSK63MRAkjMAJ91PMEFACSQ6Cw6vJ/MW3wJWSXACwCdH/Gf p8cWFPWsY1jKbYIu8WO9VsI= =fhB2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Hi Rene, Rene Engelhard wrote: ROTL. Not everything the LSB says makes sense. The OOo build system *has* support for building debs. Use this. This unfortunately does not work for people not building their own OOo. A while ago it was planned (->Martin H.: any news on this?) to provide .debs for Sun Hamburg build OOo installation sets as well as RPMs. I _am_ using Debian and would have loved to add OpenOffice.org to my sources.list (as well as Mozilla.org, ...). I think it's not the role of the software developpers to distribute the software, just like it's not the role of package maintainers to develop software. If they patch the code, normally they should contribute their patches back in IssueZilla. I tend to disagree here (see above :-), if all products / software would be provided as packages by their developers, there would be far less incompatibilities between the distributions, and one wouldn't need to Then you don't have experience with this. Sorry, but this is completely wrong, and in any case you can't then add fixes either. (see clophs post for example) Could you please elaborate? wait until a particular distribution would provide the latest package of a particular product ... That's the distributions' issue. EXACTLY Regards, Rene Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Am Dienstag, 27. Juni 2006 13:26 schrieb Kay Ramme - Sun Germany - Hamburg: > > That's the distributions' issue. > EXACTLY No. It's not. You mean that it's a problem for *you*. I mean outdated packages in a distribution is _at first_ a problem of that *distri itself*. That real outdated packaegs in development branches may become a problem is right, yes. Even in stable things when you don't get proper security patches for it (the bad example is Mozilla) But for released products, nothing would've changed. We still ship 1.1.3 in stable That never will change until the next stable release - planned in Dec - (which currently is planned to have 2.0.3, 2.0.4/2.1/2.4 will come September and the freeze is October. Quite risky...) Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 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]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Hi Jane, On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote: > 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>: > >Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit: > >> > - OOo should not attempt to build its own packages, at least under > >Linux. > >> > Under Linux, that's the distributions' work! > >> > This problem is related to the "make install" one. > >> > >> In my opinion, OOo is showing the right approach here, it is IMHO > >> unfortunate and a waste of time, that everybody patches and builds > >> everything by its own, leading to small incompatibilities and bugs here > >> and there ... > [...] > I am trying to fit OOo2 into our sourcebuilding packaging system, and I > agree with your point. > Having to go over rpms feels "stupid" in a way where not everything is meant > to end up at > /usr/local or where linux isn't necessarily implying you use (and like) > rpms. A make install that would install everything in the same default prefix as the rpms would not make any difference at all. OOo is relocatable, so if you don't like the contents of /opt/openoffice.org2.0 somewhere else. If you (like many distros) split the ooo-files around different places in the filesystem, then a make install would not help you either. You would have to pick & move files yourself as well. ciao Christian -- NP: Silverchair - Shade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote: > 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>: > >Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit: > >> > - OOo should not attempt to build its own packages, at least under > >Linux. > >> > Under Linux, that's the distributions' work! > >> > This problem is related to the "make install" one. > >> > >> In my opinion, OOo is showing the right approach here, it is IMHO > >> unfortunate and a waste of time, that everybody patches and builds > >> everything by its own, leading to small incompatibilities and bugs here > >> and there ... > [...] > I am trying to fit OOo2 into our sourcebuilding packaging system, and I > agree with your point. > Having to go over rpms feels "stupid" in a way where not everything is meant > to end up at > /usr/local or where linux isn't necessarily implying you use (and like) > rpms. A make install that would install everything in the same default prefix as the rpms would not make any difference at all. It's fine that OOo is relocatable, just rpm's usually arent, whereas stuff doing configure;make;make install usually are. Actually, it wouldn't matter if it were .deb's or stuff packed with ARJ. It's the point of having some kind of command that would move the built files from their location to a tree at $PREFIX (or $DESTDIR) w/o going via some alien package format first. For those doing development, I could imagine this would be kind of hard on the I/O. OOo is relocatable, so if you don't like the contents of /opt/openoffice.org2.0 somewhere else. If you (like many distros) split the ooo-files around different places in the filesystem, then a make install would not help you either. You would have to pick & move files yourself as well. We don't. But the idea of building from source, getting rpms, (having to build rpm itself) and then extracting from rpms, piping through cpio and lastly putting the files where they should end up sounds weird to me. -- Some mornings, it's just not worth gnawing through the straps...
Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)
Hi Janne, On Tue, Jun 27, 2006 at 04:10:01PM +0200, Janne Johansson wrote: > >On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote: > >> 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>: > [...] > It's fine that OOo is relocatable, just rpm's usually arent, whereas stuff > doing > configure;make;make install usually are. Again not true. While building rpms I learned often enough that when you want a prefix other than the default you need to patch the makefiles or even touch the source itself. And that is while building from source, so let alone the binaries. ciao Christian -- NP: Limp Bizkit - Almost Over - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
