Re: Access2Base - New release
On Tue, Jun 17, 2014 at 10:05 AM, David Tardon dtar...@redhat.com wrote: IMHO there are just two alternatives: Either the code is ours, in which case it should be an optional component and should only be updated together with libreoffice. Or it is external, in which case the sources should not be duplicated in our repo, but the project should be treated as another one of the dozen extensions we allow to bundle. That means, download the .oxt during build, unpack it, put it to instdir and be done with it. (This is directly supported by gbuild, using gb_ExtensionPackageSet). FWIW, after reading this thread, I concurs with the above. The current expressed 'problem' seems a self inflicted wound, due to wanting to become 'a core part of Libreoffice' while not wanting to follow the consequences associated with that status. Norbert --- Tu ne peux pas avoir le beurre, l'argent du beurre (et la cremiere) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
Hi, On Mon, Jun 16, 2014 at 04:40:31PM +0200, Lionel Elie Mamane wrote: On Mon, Jun 16, 2014 at 03:03:48PM +0200, Christian Lohmaier wrote: On Mon, Jun 16, 2014 at 2:16 PM, Lionel Elie Mamane lio...@mamane.lu wrote: I'm sorry we are losing your input on the design of the long-term solution in master (as opposed to the stop-gap that went in). I think we already settled on this one? i.e. make it a bundled extension (as it should have been in the first place). There were worries around the issues that pushed us to move several bundled extensions to core, so the plan is: 1) Find back what these issues were. 2) Understand if they apply to Access2Base (or e.g. only native code) 3) Then we can decide to make it a bundled extension IMHO there are just two alternatives: Either the code is ours, in which case it should be an optional component and should only be updated together with libreoffice. Or it is external, in which case the sources should not be duplicated in our repo, but the project should be treated as another one of the dozen extensions we allow to bundle. That means, download the .oxt during build, unpack it, put it to instdir and be done with it. (This is directly supported by gbuild, using gb_ExtensionPackageSet). D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 13/06/14 11:45, Lionel Elie Mamane wrote: On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote: Anyway, since binary overriding isn't on the table yet my main concern was with basic where you have can have Libraries deployed in share by the enterprise, (...) I'm not sure what deployed in share means. An extension installed for all users / with unopkg --shared? I sense that this is not what you mean. Maybe by just dropping a directory + files in LibreOffice's $(instdir)/share/basic/ ? I hadn't thought of that as a good way to extend LibreOffice... Is that really how it is done? how is Access2Base delivered? (I actually don't know) but I presume it like the wizards and other basic utilities that it is located in $(instdir)/share/basic. That is the also location where Enterprise's will also deploy their macros so that they are picked up by *all* users (or at least that is where they used to do that) and with the previous proposal the possibility that a user could with an extension override say the corporate authorisation macros or whatnot. I was exploring / discussing the various possibilities, not having yet myself formed an opinion on which one is the best. Given the resistance to something general, I made up my mind on something narrow and specific, at least right now. (Anyway the user can still override say the corporate authorisation macros or whatnot by making a copy of LibreOffice into another folder, changing that copy and running that copy...) just because there may be some way around this particular example (and it is only one example) doesn't mean that there is no value in the application trying to protect it's own internal integrity and certainly it is no reason to give up it's internal integrity by inviting users to override it's core (or installed) functionality. In some corporate environment users don't have access to shell, it's also very likely that most users don't have the skills to deeply modify their environment (LD_PRELOAD etc.) I don't believe that just because an application can in some circumstances (with willful effort by a user) be led to run code it doesn't expect that it logically follows one should change the application to actively support running unexpected code (which is what you are suggesting) Above you concede that allowing this in Basic generally is probably not a good idea. But... still you propose to special case this overriding for Access2Base, I can't see how it is any different, the same argument holds and users can easily break deployed macros depending on the 'installed' version of Access2Base. Yes, especially when installing an older version of Access2Base than the one in core. Why is that a problem? They broke it, they can pick up the pieces. Similarly, the user can also get themselves in great trouble by writing a bomb threat in Writer and mailing to the White House. We don't have any protection against that. The problem is that to get into that situation in the first place you have had to allow the user to override the core behaviour with an extension, isn't that the what this discussion is all about (wasn't the first question in this thread about why there is a piece of code that enforces that such a scenario doesn't occur)? It's not about Access2Base at all (although it is obviously the trigger) it's about changing the defined behaviour (even in a limited way that effects just Access2Base) where user extensions can override/replace core functionality It's quite simple (all smokescreens about user freedom etc, aside), once this change is in a release it becomes accepted behaviour. It's then only a matter of time before the expectation is that it should work the same way for the rest of Basic, and then for consistency an expectation of the same behaviour for binary extensions an so on. Given your expressed views that this is how you would like the application to behave anyway, I find this change worrying to say the least ( caveat being if indeed the behaviour is accepted as desired ) The user can also make their environment unusable by changing the UI language to a language they don't understand. And a myriad other things... so what? On a different tack, one difference is that getting the latest Access2Base is something available to users of other branches of the code (LibreOffice 4.1 and earlier, Apache OpenOffice, ...), so here we are removing a competitive disadvantage. this isn't a justification of why the present behaviour should be broken just an explanation why it is convenient for you to do that If we consider a macro written for (and that works only with) the latest Access2Base, then it allows the user to use that macro with LibreOffice 4.2, without having to upgrade to a less tested LibreOffice 4.3. wouldn't it make more sense then to update *all* branches to the latest access2base, if it don't change that much anyway But, as I see this morning this discussion is a waste of my time, seems that
Re: Access2Base - New release
On Mon, Jun 16, 2014 at 09:53:37AM +0100, Noel Power wrote: On 13/06/14 11:45, Lionel Elie Mamane wrote: On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote: But, as I see this morning this discussion is a waste of my time, seems that this change was already in, why even bother asking for an opinion in the first place, unfortunately I find I am not surprised No, it is not a waste of time; well actually I beg to differ, (...) I'm done with this. I'm sorry we are losing your input on the design of the long-term solution in master (as opposed to the stop-gap that went in). Anyway, since binary overriding isn't on the table yet my main concern was with basic where you have can have Libraries deployed in share by the enterprise, (...) I'm not sure what deployed in share means. An extension installed for all users / with unopkg --shared? I sense that this is not what you mean. Maybe by just dropping a directory + files in LibreOffice's $(instdir)/share/basic/ ? I hadn't thought of that as a good way to extend LibreOffice... Is that really how it is done? how is Access2Base delivered? (I actually don't know) but I presume it like the wizards and other basic utilities that it is located in $(instdir)/share/basic. That is the also location where Enterprise's will also deploy their macros so that they are picked up by *all* users (or at least that is where they used to do that) I hadn't anticipated people/enterprises would to it like that. I'm trying to imagine how it would work in practice... On RPM/DEB GNU/Linux systems, dropping files in (example for Debian) /usr/lib/ ($(inst) is /usr/lib/libreoffice apparently) is heavily discouraged... Unless one does it through a deb/rpm package. That's why (in my worldview) most programs look for files in a second location, namely /usr/local/something, which is reserved for the admin. AFAIK, LibreOffice doesn't do that, I understood that the extension package kinda replaces that. On Microsoft Windows, you'd have to drop files in c:\progra~1\LibreOffice 4\share, and then move them when you upgrade to LibreOffice 5, etc. Above you concede that allowing this in Basic generally is probably not a good idea. But... still you propose to special case this overriding for Access2Base, I can't see how it is any different, the same argument holds and users can easily break deployed macros depending on the 'installed' version of Access2Base. Yes, especially when installing an older version of Access2Base than the one in core. Why is that a problem? The problem is that to get into that situation in the first place you have had to allow the user to override the core behaviour with an extension, isn't that the what this discussion is all about (wasn't the first question in this thread about why there is a piece of code that enforces that such a scenario doesn't occur)? It's not about Access2Base at all (although it is obviously the trigger) it's about changing the defined behaviour (even in a limited way that effects just Access2Base) where user extensions can override/replace core functionality Well, Access2Base was my goal (trigger) in opening the discussion; to understand the problems and concepts, I generalised them. In other words, I looked at, and discussed, the general case to understand what could be done in the specific. It's quite simple (...), once this change is in a release it becomes accepted behaviour. What is intended to become accepted behaviour, at a higher level, is that access2base can be upgraded out of cycle, by the admin and/or user, in LibreOffice. Not the particular way in which it is done. It's then only a matter of time before the expectation is that it should work the same way for the rest of Basic, and then for consistency an expectation of the same behaviour for binary extensions an so on. I don't expect such a narrow exception will lead to a slippery slope. And if we find a better way, we can remove the exception and allow upgrading access2base in some other, better, way in 4.4. Given your expressed views that this is how you would like the application to behave anyway, I find this change worrying to say the least ( caveat abeing if indeed the behaviour is accepted as desired ) I'm not the LibreOffice benevolent dictator (thus my views will not have priority), and I don't intend to push for the general case anyway. About the general case, I floated the idea, others disagree, shrug The user can also make their environment unusable by changing the UI language to a language they don't understand. And a myriad other things... so what? So trying to protect the user from themselves (which you intend to do by having LibreOffice try to protect its own internal integrity) is a loosing battle, and is not worth making the hacker user's life more miserable. If we consider a macro written for (and that works only with) the latest Access2Base, then it allows the user to use that
Re: Access2Base - New release
Hi Lionel, *; On Mon, Jun 16, 2014 at 2:16 PM, Lionel Elie Mamane lio...@mamane.lu wrote: On Mon, Jun 16, 2014 at 09:53:37AM +0100, Noel Power wrote: On 13/06/14 11:45, Lionel Elie Mamane wrote: On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote: But, as I see this morning this discussion is a waste of my time, seems that this change was already in, why even bother asking for an opinion in the first place, unfortunately I find I am not surprised No, it is not a waste of time; well actually I beg to differ, (...) I'm done with this. I'm sorry we are losing your input on the design of the long-term solution in master (as opposed to the stop-gap that went in). I think we already settled on this one? i.e. make it a bundled extension (as it should have been in the first place). [...] What is intended to become accepted behaviour, at a higher level, is that access2base can be upgraded out of cycle, by the admin and/or user, in LibreOffice. Not the particular way in which it is done. And that is why it should be an extension and that overriding the bundled stuff should stay the exception. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Mon, Jun 16, 2014 at 03:03:48PM +0200, Christian Lohmaier wrote: On Mon, Jun 16, 2014 at 2:16 PM, Lionel Elie Mamane lio...@mamane.lu wrote: I'm sorry we are losing your input on the design of the long-term solution in master (as opposed to the stop-gap that went in). I think we already settled on this one? i.e. make it a bundled extension (as it should have been in the first place). There were worries around the issues that pushed us to move several bundled extensions to core, so the plan is: 1) Find back what these issues were. 2) Understand if they apply to Access2Base (or e.g. only native code) 3) Then we can decide to make it a bundled extension People's memory says there were some issues around upgrade scenarios. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
Hi, I read the whole thread and tried to understand, tried because I'm not enough fluent in these technical/internal LO part. Why A2B must be quickly (I mean without waiting for next LO version) upgradable? Either it's stable and so we don't absolutely need to upgrade it quickly or it's unstable and therefore it shouldn't access to LO core parts anyway. In first case, A2B could be bundled extension, in the second case a simple extension because there'll be fix upgrades to become stable (or at least enough stable). So if A2B can be considered as enough stable and therefore can be a bundled extension, it means fixes from A2B can be included in the different versions (not only major) from LO 4.3.1, 4.3.2, etc. (like external libs) Now about new LO version which would include last patches from A2B compared with old LO version, yes companies should upgrade in this case or they're still have the possibility to build LO from the sources with the required patches, they're free to do it as we're free to try to harden LO a bit. In conclusion IMHO b534967caca6767cd2100da363b1da2433640ddd should be reverted. Julien -- View this message in context: http://nabble.documentfoundation.org/Access2Base-New-release-tp4108421p4112581.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 12/06/14 16:16, Lionel Elie Mamane wrote: On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote: On 28/05/14 12:11, Lionel Elie Mamane wrote: [...] you are just stating how you want it to work, it's not a justification No, that was my prediction from reading the code that implements that. I now *tested*, in plain 4.2.4.2 (Debian amd64 package), that it indeed behaves in that way, by: 1) Installing Foo as a user extension 2) Observe result: Libraries Quux And Frobotz (from Foo) are enabled and available. 3) Install Bar as a user extension 4) Observe result: * Library Frobotz is still there and available (from Foo) * Library Quux from Foo is nowhere to be found in the Library browser. * Library Quux from Bar is enabled and present, and can be used. I took it (or thought that I read it) that the description above was how you wish it to behave when installing a user extension against an existing share Basic Library. [...] Security, I mentioned it in a previous mail, what you are suggesting is basically allowing the user to rootkit the libreoffice api. I'm surprised you consider LibreOffice a security barrier / enforcer. I don't. As I see it, factually, it is an application that runs with the user's identity and privileges, that is under the control of the user and of anybody that subverts the user's environment. If you are thinking in terms of security, well LD_PRELOAD / LD_LIBRARY_PATH allows overriding any binary part of LibreOffice anyway. As does LD_PRELOAD'ing a library that redefines open() to override any part of LibreOffice (Python code, Basic, dialog .ui, ...). sure you can do anything you want, but I am not talking about a convoluted and technically complicated scenario like wrapping various libreoffice libraries. It's clear you are comfortable with the idea that a user extension can override the core, a hypothetical example being say of a user installing a user extension that overrides the allows a user XProtectable so they can easily unlock any spreadsheet to unhide their bosses salary. But... the issue here isn't the silly example it's the fact that libreoffice itself uses the api, it expects the code it calls via the api to be the code it shipped with and to behave exactly how it expects, this is one of the boundaries (or at least how I read it) that Michael mentioned previously and one of the invariants the core expects. The key is in the name, extensions extend, not override In the binary case the possibilities should be clear. But even if Libreoffice didn't ship any basic libraries as part of the core it wouldn't change the fact that enterprises normally deploy all of their macros in share, I doubt they would wish that a user could 'override' any libraries (including Access2Base that possibly some of their macros have a dependency on) Enterprises are free, if they so wish, to forbid their employees to install an extension that overrides a part of core, or otherwise override a part of LibreOffice core. first they need to know that they need to tell their users not to do that, then they got to believe that users will obey them or understand, but I suppose they could always customise libreoffice so that the extension functionality is not available or go through a hundred other hoops they never had to know about or consider before... I think that a (semi-)structured / (semi-)controlled (that is, extensions) way of overriding more-or-less arbitrary parts of a program is much better than having to resort to LD_PRELOAD / LD_LIBRARY_PATH, but that's not my fight, and (obviously) not a change we'd introduce in a stable branch. see above, and I fail to see how lowering the barrier to for people to do bad (intentionally or not) things is a good idea, Anyway, since binary overriding isn't on the table yet my main concern was with basic where you have can have Libraries deployed in share by the enterprise, and with the previous proposal the possibility that a user could with an extension override say the corporate authorisation macros or whatnot. Above you concede that allowing this in Basic generally is probably not a good idea. But... still you propose to special case this overriding for Access2Base, I can't see how it is any different, the same argument holds and users can easily break deployed macros depending on the 'installed' version of Access2Base. FWIIW, an enterprise could also wish to deploy a newer Access2Base version without upgrading to LibreOffice Fresh (because they are enterprise, they want Stable), because it suits their newly developed macros better... And then doing it by a system-wide extension is much better than having to recompile the whole of LibreOffic in that case the Enterprise has made the decision for themselves that part of the libreoffice installation has been updated, you want to take the decision out of the Adminstrators hands and into the users, that is bad policy. If the updating of basic
Re: Access2Base - New release
On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote: Anyway, since binary overriding isn't on the table yet my main concern was with basic where you have can have Libraries deployed in share by the enterprise, (...) I'm not sure what deployed in share means. An extension installed for all users / with unopkg --shared? I sense that this is not what you mean. Maybe by just dropping a directory + files in LibreOffice's $(instdir)/share/basic/ ? I hadn't thought of that as a good way to extend LibreOffice... Is that really how it is done? and with the previous proposal the possibility that a user could with an extension override say the corporate authorisation macros or whatnot. I was exploring / discussing the various possibilities, not having yet myself formed an opinion on which one is the best. Given the resistance to something general, I made up my mind on something narrow and specific, at least right now. (Anyway the user can still override say the corporate authorisation macros or whatnot by making a copy of LibreOffice into another folder, changing that copy and running that copy...) Above you concede that allowing this in Basic generally is probably not a good idea. But... still you propose to special case this overriding for Access2Base, I can't see how it is any different, the same argument holds and users can easily break deployed macros depending on the 'installed' version of Access2Base. Yes, especially when installing an older version of Access2Base than the one in core. Why is that a problem? They broke it, they can pick up the pieces. Similarly, the user can also get themselves in great trouble by writing a bomb threat in Writer and mailing to the White House. We don't have any protection against that. The user can also make their environment unusable by changing the UI language to a language they don't understand. And a myriad other things... On a different tack, one difference is that getting the latest Access2Base is something available to users of other branches of the code (LibreOffice 4.1 and earlier, Apache OpenOffice, ...), so here we are removing a competitive disadvantage. If we consider a macro written for (and that works only with) the latest Access2Base, then it allows the user to use that macro with LibreOffice 4.2, without having to upgrade to a less tested LibreOffice 4.3. FWIIW, an enterprise could also wish to deploy a newer Access2Base version without upgrading to LibreOffice Fresh (because they are enterprise, they want Stable), because it suits their newly developed macros better... And then doing it by a system-wide extension is much better than having to recompile the whole of LibreOffic in that case the Enterprise has made the decision for themselves that part of the libreoffice installation has been updated, you want to take the decision out of the Adminstrators hands and into the users, that is bad policy. If the updating of basic libraries was limited to shared (for-all) extenions e.g. normally only able to be done by the administrator then this whole thing would be a hell of a lot less evil (but still wrong imho) Well, the setup that I consider as usual is user trumps admin trumps software author. That's why e.g. $PATH usually is something like (when these directories exist): $HOME/bin:/usr/local/bin:/usr/bin and *not* hardcoded-without-possibility-to-change: /usr/bin:/usr/local/bin:$HOME/bin That's why e.g. mutt (my MUA) has for settings: 1) defaults set by the software author 2) that are overridden by settings in /etc/Muttrc 3) that are overridden by settings in $HOME/.muttrc etc, etc, etc. But, as I see this morning this discussion is a waste of my time, seems that this change was already in, why even bother asking for an opinion in the first place, unfortunately I find I am not surprised No, it is not a waste of time; your opinion is valuable and is listened to; for example the narrowing to make it an exception for access2base only. Also, the change is in, *but* it is in as a stop-gap measure, to make the smallest, most well tested change that solves the problem, while a more sane solution is investigated. Turning access2base into a bundled extension in *master* (or some other yet-to-be-devised solution) is still on the table. There were for example worries around upgrade scenarios, and problems arising from bundled extension in the past. Do these problems apply to Access2Base? After this is investigated, we can (in master) revert this change, and apply a saner solution. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
What I don't understand is why Access2Base needs to be bundled with LO if it is developed on a so completely different schedule that there will be new versions to install more often than LO is updated? But then, I don't really personally care either way, especially as I am *this* close to being on vacation. This is my personal opinion. If you like it, your can have it too. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Fri, Jun 13, 2014 at 01:53:23PM +0300, Tor Lillqvist wrote: What I don't understand is why Access2Base needs to be bundled with LO if it is developed on a so completely different schedule that there will be new versions to install more often than LO is updated? Well, need is a strong word. Being advantageous is what I would say. For the time being, the schedule has actually been rather synchronised: the new version of access2base came at the right time for LibreOffice 4.3. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 13/06/2014 12:53, Tor Lillqvist wrote: What I don't understand is why Access2Base needs to be bundled with LO if it is developed on a so completely different schedule that there will be new versions to install more often than LO is updated? The rythm of major releases of Access2Base is twice every year, as for LO. So, that's not the issue. But Access2Base existed as an extension before being bundled with LO 4.2. The issue is: - LO 4.1 users (btw AOO users as well ...) shall be able to install the latest A2B version (as an extension), when it will be published, i.e. simultaneously with LO 4.3.0. - LO 4.3 users will get the latest A2B version - However LO 4.2 users who, for any reason, would like not to upgrade to LO 4.3 immediately , would stay in the older version. Indeed minor releases of LO (4.2.X++) allow bug fixes, not functional enhancements. That's why a patch has been developed by Lionel to allow the installation of the A2B extension anyway if users really want to benefit from its last version. Have a nice vacation. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote: On 28/05/14 12:11, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote: On 19/05/14 15:59, Lionel Elie Mamane wrote: [...] addition, but not replacement, especially not potentially partial replacement. with a bundled extension it would work to replace it, because there LO knows the boundaries of what is being replaced and can disable the whole bundled extension; I don't buy that it does that. If (bundled, or system-installed) extension Foo ships Basic libraries Quux and Frobotz, and then the user installs extension Bar that ships Basic library Quux, but not Frobotz, then IMO the result is: 1) Basic library Quux from Foo is disabled. 2) Basic library Frobotz from Foo stays enabled. 3) Basic library Quux from Bar is enabled. you are just stating how you want it to work, it's not a justification No, that was my prediction from reading the code that implements that. I now *tested*, in plain 4.2.4.2 (Debian amd64 package), that it indeed behaves in that way, by: 1) Installing Foo as a user extension 2) Observe result: Libraries Quux And Frobotz (from Foo) are enabled and available. 3) Install Bar as a user extension 4) Observe result: * Library Frobotz is still there and available (from Foo) * Library Quux from Foo is nowhere to be found in the Library browser. * Library Quux from Bar is enabled and present, and can be used. Now, if I *restart* LibreOffice, it seems to be rather undefined whether Quux is taken from Foo or from Bar. My guess is that it depends on the initialisation order of the extensions. This depends on initialisation order undefinedness / problem can (my guess) not arise in the scenario of an extension overriding a Basic library in core. I'm much less sure about what happens when: * Foo is system-installed or bundled, and Quux is user-installed * Foo is bundled and Quux is system-installed Do we have a well-defined priority order there? And I'm pretty sure the problem arises when: * Foo and Quux are both system-installed * Foo and Quux are both user-installed Another problem: When I uninstall Foo, Bar is broken. Its Quux library is listed, but empty. Now, in the scenarios that concern Access2Base, IMO: 1) In the short term, by leaving access2base in core and allowing to be overriden by an extension, we avoid the possibility of both the above problems. 2) In longer term, people that want to make access2base a bundled extension (or some other saner solution) need to ensure that the problem of undefined priority will not arise; I rather expect that we have an explicit priority order like: bundled yields to system-installed yields to user-installed *but* I'd like to have this checked before making access2base a bundled extension. I *expect* that when the bundled extension and the user (or system) installed extensions have the same name, the uninstall Foo maims Bar problem does not happen, but please ensure that, too. if you want to bundle something that can be replaced by the user, do it as a bundled extension. How about we put an exception in the code that only Basic (and Dialog?) libraries, or maybe only access2base, can be overridden by an extension? I don't think we ship any actual feature as Basic code - only examples (I'm less sure about Dialog libraries), so it will not hurt. why should there be an exception for Basic, there is no possibly justification for that, oh, hang on I think I can hear it coming, well we don't really ship anything in terms of api with Basic at the moment, so... it won't break anything But it does, there are at least library functions and wizards, OK, if we ship wizards as Basic code, then indeed exception for Basic is not a good idea. I didn't see any from a cursory glance. but... in anycase the principle is the same. It all boils down to the fact that if you want to provide updated and incompatible api then you don't do that in the release branches, Yes, I agree with that. I want the user to have the *optional* possibility to go to another / newer API (they are supposed to be backwards compatible FWIIW). that's what master is for, if you want something (e.g. access2base) to act like and extension (that provides a different update strategy) then just make it an extension See above. And here, the boundaries are very clear, known by the code and handled well by the code: one Basic library. I mean add to the code a case like this: || sOriginalUrl.match($(INST)/share/basic) or || sOriginalUrl.match($(INST)/share/basic/Access2Base) Or should it be something like || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/share/basic/Access2Base) or || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR/basic/Access2Base) ? It avoids us demoting Access2Base to a bundled extension. yeah, my
Re: Access2Base - New release
On Thu, Jun 12, 2014 at 05:16:45PM +0200, Lionel Elie Mamane wrote: On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote: In the binary case the possibilities should be clear. But even if Libreoffice didn't ship any basic libraries as part of the core it wouldn't change the fact that enterprises normally deploy all of their macros in share, I doubt they would wish that a user could 'override' any libraries (including Access2Base that possibly some of their macros have a dependency on) Enterprises are free, if they so wish, to forbid their employees to install an extension that overrides a part of core, or otherwise override a part of LibreOffice core. FWIIW, an enterprise could also wish to deploy a newer Access2Base version without upgrading to LibreOffice Fresh (because they are enterprise, they want Stable), because it suits their newly developed macros better... And then doing it by a system-wide extension is much better than having to recompile the whole of LibreOffice. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 28/05/14 12:11, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote: On 19/05/14 15:59, Lionel Elie Mamane wrote: [...] addition, but not replacement, especially not potentially partial replacement. with a bundled extension it would work to replace it, because there LO knows the boundaries of what is being replaced and can disable the whole bundled extension; I don't buy that it does that. huh? extensions are built on top of and using the stable (well as stable as libreoffice ever is) api, if you allow 'other' extensions to change the 'core' api (with no way of knowing that the base system has been changed) then well good luck with stability If (bundled, or system-installed) extension Foo ships Basic libraries Quux and Frobotz, and then the user installs extension Bar that ships Basic library Quux, but not Frobotz, then IMO the result is: 1) Basic library Quux from Foo is disabled. 2) Basic library Frobotz from Foo stays enabled. 3) Basic library Quux from Bar is enabled. you are just stating how you want it to work, it's not a justification but when replacing something that's built-in you can't assume that it was ever designed to be replaced, It's FLOSS, it can always be replaced by a binary-compatible fork of it: a bug fixed, a feature added in a compatible way, a version that logs what the user does, a version that bills printed pages to the appropriate customer (by hooking into the printing function), ... I don't even understand the argument, but... hey if you are saying that someone can build various libraries and components and shove them into a libreoffice installation then sure, they could do it, they are free to do it but would you actually provide support for them to do that you can end up with a mixture of built-in files and extension files loaded that doesn't work. Yes. if you want to bundle something that can be replaced by the user, do it as a bundled extension. How about we put an exception in the code that only Basic (and Dialog?) libraries, or maybe only access2base, can be overridden by an extension? I don't think we ship any actual feature as Basic code - only examples (I'm less sure about Dialog libraries), so it will not hurt. why should there be an exception for Basic, there is no possibly justification for that, oh, hang on I think I can hear it coming, well we don't really ship anything in terms of api with Basic at the moment, so... it won't break anything But it does, there are at least library functions and wizards, but... in anycase the principle is the same. It all boils down to the fact that if you want to provide updated and incompatible api then you don't do that in the release branches, that's what master is for, if you want something (e.g. access2base) to act like and extension (that provides a different update strategy) then just make it an extension And here, the boundaries are very clear, known by the code and handled well by the code: one Basic library. I mean add to the code a case like this: || sOriginalUrl.match($(INST)/share/basic) or || sOriginalUrl.match($(INST)/share/basic/Access2Base) Or should it be something like || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/share/basic/Access2Base) or || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR/basic/Access2Base) ? It avoids us demoting Access2Base to a bundled extension. yeah, my feeling here is avoiding this perceived 'demotion' of Access2Base is what this debate is about and not a genuine technical need or bug. I hope I am wrong. Truth is though bundled or not, users won't care or notice. Surely the fact that it is supported, it is isn't it? (otherwise what's the point??) is IMHO the important point or issue for users. That would be what discriminates it from other bundled extensions (I bet many users expect are all bundled extensions are supported regardless) On Mon, May 19, 2014 at 04:39:36PM +0100, Noel Power wrote: On 19/05/14 14:59, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: [...] Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, (...) Access2Base is either part of the product or it's not. I don't think this was a very conscious decision. Access2Base started its life as an extension that got integrated into LibreOffice, but is still available as an extension for other branches / forks of the code. It got shipped as part of the product since that was easier to set up and LibreOffice was (my perception) moving away from bundled extensions anyway. IMHO moving away == moving functionality into the core = stable api with the same rules as the rest of the code I tend to agree as to what we ship, but not as to what the user is allowed to override; if (s)he wants to have an updated API by explicitly installing an
Re: Access2Base - New release
On Mon, May 19, 2014 at 04:33:03PM +0200, Michael Stahl wrote: On 19/05/14 15:59, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: On 19/05/14 08:23, Stephan Bergmann wrote: On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote: [...] So, the question is why does this code enforce this condition, and can we change it? Can we just remove the condition altogether, or should we add this case: || sOriginalUrl.match($(INST)) (...) you are talking about trying to override a built-in library with an extension, Yes. it seems ato me that you are trying to get around the rules of no-new features etc. by exploiting the extension mechanism. No, extensions are *very* *much* *designed* to allow addition of new features to LibreOffice! addition, but not replacement, especially not potentially partial replacement. with a bundled extension it would work to replace it, because there LO knows the boundaries of what is being replaced and can disable the whole bundled extension; I don't buy that it does that. If (bundled, or system-installed) extension Foo ships Basic libraries Quux and Frobotz, and then the user installs extension Bar that ships Basic library Quux, but not Frobotz, then IMO the result is: 1) Basic library Quux from Foo is disabled. 2) Basic library Frobotz from Foo stays enabled. 3) Basic library Quux from Bar is enabled. but when replacing something that's built-in you can't assume that it was ever designed to be replaced, It's FLOSS, it can always be replaced by a binary-compatible fork of it: a bug fixed, a feature added in a compatible way, a version that logs what the user does, a version that bills printed pages to the appropriate customer (by hooking into the printing function), ... you can end up with a mixture of built-in files and extension files loaded that doesn't work. Yes. if you want to bundle something that can be replaced by the user, do it as a bundled extension. How about we put an exception in the code that only Basic (and Dialog?) libraries, or maybe only access2base, can be overridden by an extension? I don't think we ship any actual feature as Basic code - only examples (I'm less sure about Dialog libraries), so it will not hurt. And here, the boundaries are very clear, known by the code and handled well by the code: one Basic library. I mean add to the code a case like this: || sOriginalUrl.match($(INST)/share/basic) or || sOriginalUrl.match($(INST)/share/basic/Access2Base) Or should it be something like || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/share/basic/Access2Base) or || sOriginalUrl.match(vnd.sun.star.expand:$BRAND_BASE_DIR/$BRAND_SHARE_SUBDIR/basic/Access2Base) ? It avoids us demoting Access2Base to a bundled extension. On Mon, May 19, 2014 at 04:39:36PM +0100, Noel Power wrote: On 19/05/14 14:59, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: [...] Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, (...) Access2Base is either part of the product or it's not. I don't think this was a very conscious decision. Access2Base started its life as an extension that got integrated into LibreOffice, but is still available as an extension for other branches / forks of the code. It got shipped as part of the product since that was easier to set up and LibreOffice was (my perception) moving away from bundled extensions anyway. IMHO moving away == moving functionality into the core = stable api with the same rules as the rest of the code I tend to agree as to what we ship, but not as to what the user is allowed to override; if (s)he wants to have an updated API by explicitly installing an extension, why not? But in anycase although Access2Base is part of the core, part of the product etc. it is afaik completely selfcontained (and essentially a separately maintained subsystem) in this case I think there is a good argument to bend the rules regarding updating the version of Access2Base shipped, we already do that occasionly I think? Well, that means we ship a changing API into our stable line (I mean patchlevel updates). I'm not comfortable with this. I'd be far much comfortable if people that wanted the changed API installed it explicitly as an extension. then Access2Base should be an extension, they are designed with that in mind, a bundled extension would have been a better choice, it at least gives the illusion of being part of the product whilst giving more flexibility. I don't know what the answer is here, personally I don't have a problem with Access2Base being updated given what I said above, but I don't believe replacing non-extension code (be-it binary or script) with extension code is a good idea See above. -- Lionel ___ LibreOffice mailing
Re: Access2Base - New release
On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote:
I took a deeper look at it; actually, the problem is different. A
user-installed extension *is* allowed to override a Basic script (or
dialog) library from a *bundled* *extension*, or from a *system*
(installed as for all users) extension. *But* not to override a
script (or dialog) library that forms an integral part of
LibreOffice. And access2base is (in LibreOffice 4.2) not a bundled
extension, but a standard part of LibreOffice.
The code that enforces that is:
desktop/source/deployment/registry/script/dp_script.cxx around line 350:
if
(sOriginalUrl.match(vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE)
||
sOriginalUrl.match(vnd.sun.star.expand:$UNO_SHARED_PACKAGES_CACHE)
||
sOriginalUrl.match(vnd.sun.star.expand:$BUNDLED_EXTENSIONS))
{
xScriptLibs-removeLibrary(rName);
bCanAdd = true;
}
else
{
bCanAdd = false;
}
However, if I direct the code flow into the if branch anyway with gdb,
then everything goes well, the built-in access2base is disabled and
the one from the user-installed extension takes over.
So, the question is why does this code enforce this condition, and
can we change it? Can we just remove the condition altogether, or
should we add this case:
|| sOriginalUrl.match($(INST))
Noel? Uray? You are our Basic FindTheExperts. What's your opinion on
this?
Most likely, the reason that that desktop/source/deployment code only
checks against existing extension libraries but not built-in ones is
that that was never a use-case the code was designed for. I do not
know, though,whether there are any gotchas on the BASIC side that would
be enabled by your proposed change.
Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 19/05/14 08:23, Stephan Bergmann wrote: On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote: [...] So, the question is why does this code enforce this condition, and can we change it? Can we just remove the condition altogether, or should we add this case: || sOriginalUrl.match($(INST)) Noel? Uray? You are our Basic FindTheExperts. What's your opinion on this? So I wasn't following this, I was away for the last week anyway and while reverse scanning my mail I stumbled on this. It seems to me that the code there (which I admit I am not familiar with) is all to do with extensions and management of extensions right? In this case you are talking about trying to override a built-in library with an extension, the code it would seem rightly tries to prevent an extension from doing that. I mean there are wizards, conversions, routines etc. that are considered part of the system that shouldn't be 'replaced' under the hood. Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, it seems to me that you are trying to get around the rules of no-new features etc. by exploiting the extension mechanism. Access2Base is either part of the product or it's not. Also doesn't the code mentioned above actually try and remove the existing library? perhaps the librarycontainer does something special in this case, I don't know. But in anycase although Access2Base is part of the core, part of the product etc. it is afaik completely selfcontained (and essentially a separately maintained subsystem) in this case I think there is a good argument to bend the rules regarding updating the version of Access2Base shipped, we already do that occasionly I think? Most likely, the reason that that desktop/source/deployment code only checks against existing extension libraries but not built-in ones is that that was never a use-case the code was designed for. I do not know, though,whether there are any gotchas on the BASIC side that would be enabled by your proposed change. shrug I'm not sure, I know any duplicate symbols (and it can happen in libreoffice basic) can cause unexpected and suprising results, imho they shouldn't be allowed but that's another story. I'm still not sure what actually happens when such a scenario as above is forced, is the 'old' library removed or not, if not does the 'old' library actually get compiled even, what happens later when upgrading, does it set a precedent for binary extensions to be able to replace 'system' components (if that isn't already possible) etc. Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: On 19/05/14 08:23, Stephan Bergmann wrote: On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote: [...] So, the question is why does this code enforce this condition, and can we change it? Can we just remove the condition altogether, or should we add this case: || sOriginalUrl.match($(INST)) Noel? Uray? You are our Basic FindTheExperts. What's your opinion on this? It seems to me that the code there (which I admit I am not familiar with) is all to do with extensions and management of extensions right? In this case you are talking about trying to override a built-in library with an extension, Yes. the code it would seem rightly tries to prevent an extension from doing that. I mean there are wizards, conversions, routines etc. that are considered part of the system that shouldn't be 'replaced' under the hood. Naively, why not? If an extension wants to improve one of our wizards or conversion, why forbid it? Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, (...) Access2Base is either part of the product or it's not. I don't think this was a very conscious decision. Access2Base started its life as an extension that got integrated into LibreOffice, but is still available as an extension for other branches / forks of the code. It got shipped as part of the product since that was easier to set up and LibreOffice was (my perception) moving away from bundled extensions anyway. it seems ato me that you are trying to get around the rules of no-new features etc. by exploiting the extension mechanism. No, extensions are *very* *much* *designed* to allow addition of new features to LibreOffice! Also doesn't the code mentioned above actually try and remove the existing library? perhaps the librarycontainer does something special in this case, I don't know. Yes, it removes the existing library. I tried it (by changing the code flow to go into the if instead of the else), and it just works. The part of the product library just disappears from the LibreOffice Macros list, and the one from the extension goes into My Macros (for a user-installed extension). When the extension is removed, after a restart of LibreOffice the part of the product library appears again. But in anycase although Access2Base is part of the core, part of the product etc. it is afaik completely selfcontained (and essentially a separately maintained subsystem) in this case I think there is a good argument to bend the rules regarding updating the version of Access2Base shipped, we already do that occasionly I think? Well, that means we ship a changing API into our stable line (I mean patchlevel updates). I'm not comfortable with this. I'd be far much comfortable if people that wanted the changed API installed it explicitly as an extension. Most likely, the reason that that desktop/source/deployment code only checks against existing extension libraries but not built-in ones is that that was never a use-case the code was designed for. I do not know, though,whether there are any gotchas on the BASIC side that would be enabled by your proposed change. shrug I'm not sure, I know any duplicate symbols (and it can happen in libreoffice basic) can cause unexpected and suprising results, imho they shouldn't be allowed but that's another story. I'm still not sure what actually happens when such a scenario as above is forced, is the 'old' library removed or not, See above. removed, I would rather say disabled as long as the extension is installed. if not does the 'old' library actually get compiled even, n/a what happens later when upgrading, Not tested, but I guess the library from the extension continues to override the built-in one. does it set a precedent for binary extensions to be able to replace 'system' components (if that isn't already possible) etc. Maybe I'm naive, but I'm in principle OK with that; an extension that breaks something when doing that gets to pick up the pieces. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 19/05/14 15:59, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: On 19/05/14 08:23, Stephan Bergmann wrote: On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote: [...] So, the question is why does this code enforce this condition, and can we change it? Can we just remove the condition altogether, or should we add this case: || sOriginalUrl.match($(INST)) Noel? Uray? You are our Basic FindTheExperts. What's your opinion on this? It seems to me that the code there (which I admit I am not familiar with) is all to do with extensions and management of extensions right? In this case you are talking about trying to override a built-in library with an extension, Yes. the code it would seem rightly tries to prevent an extension from doing that. I mean there are wizards, conversions, routines etc. that are considered part of the system that shouldn't be 'replaced' under the hood. Naively, why not? If an extension wants to improve one of our wizards or conversion, why forbid it? this has the potential to create hard-to-debug failures. Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, (...) Access2Base is either part of the product or it's not. I don't think this was a very conscious decision. Access2Base started its life as an extension that got integrated into LibreOffice, but is still available as an extension for other branches / forks of the code. It got shipped as part of the product since that was easier to set up and LibreOffice was (my perception) moving away from bundled extensions anyway. it seems ato me that you are trying to get around the rules of no-new features etc. by exploiting the extension mechanism. No, extensions are *very* *much* *designed* to allow addition of new features to LibreOffice! addition, but not replacement, especially not potentially partial replacement. with a bundled extension it would work to replace it, because there LO knows the boundaries of what is being replaced and can disable the whole bundled extension; but when replacing something that's built-in you can't assume that it was ever designed to be replaced, you can end up with a mixture of built-in files and extension files loaded that doesn't work. if you want to bundle something that can be replaced by the user, do it as a bundled extension. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 19/05/14 14:59, Lionel Elie Mamane wrote: On Mon, May 19, 2014 at 11:06:46AM +0100, Noel Power wrote: [...] Access2Base is considered a part of the core isn't it? it isn't shipped as an extention, it is shipped as part of the product, (...) Access2Base is either part of the product or it's not. I don't think this was a very conscious decision. Access2Base started its life as an extension that got integrated into LibreOffice, but is still available as an extension for other branches / forks of the code. It got shipped as part of the product since that was easier to set up and LibreOffice was (my perception) moving away from bundled extensions anyway. IMHO moving away == moving functionality into the core = stable api with the same rules as the rest of the code it seems ato me that you are trying to get around the rules of no-new features etc. by exploiting the extension mechanism. No, extensions are *very* *much* *designed* to allow addition of new features to LibreOffice! sure extensions are very much designed to add new functionality (also independantly updateable from thing (libreoffice) they extend ) they are not designed to replace in an uncontrolled way core functionality, that leads to a maintenance (security??) nightmare scenarios [...] But in anycase although Access2Base is part of the core, part of the product etc. it is afaik completely selfcontained (and essentially a separately maintained subsystem) in this case I think there is a good argument to bend the rules regarding updating the version of Access2Base shipped, we already do that occasionly I think? Well, that means we ship a changing API into our stable line (I mean patchlevel updates). I'm not comfortable with this. I'd be far much comfortable if people that wanted the changed API installed it explicitly as an extension. [...] then Access2Base should be an extension, they are designed with that in mind, a bundled extension would have been a better choice, it at least gives the illusion of being part of the product whilst giving more flexibility. I don't know what the answer is here, personally I don't have a problem with Access2Base being updated given what I said above, but I don't believe replacing non-extension code (be-it binary or script) with extension code is a good idea does it set a precedent for binary extensions to be able to replace 'system' components (if that isn't already possible) etc. Maybe I'm naive, but I'm in principle OK with that; an extension that breaks something when doing that gets to pick up the pieces. pity then the poor developers trying to debug some crazy (and unobvious) mixture of unsupported and supported (core) code not really realising what is what Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 15/05/2014 12:30, Lionel Elie Mamane wrote: one might hope that when loading the library, one source is always preferred over the other. After a test the behaviour of LibreOffice is found sane: when installing an extension with the same name as a pre-installed one, the extension gets INSTALLED but cannot be ENABLED. So the pre-existing one keeps the precedence. (BTW I tried 6 months ago upgrading (LO 4.1 + A2B extension) to LO 4.2 = the conclusion was that A2B needed to be uninstalled before the upgrade.) I presume it is compliant with the LO release policy to push the same patch also to the LO 4.2 branch ? I don't think so; no new features, only bugfixes. So, what do you recommend ? Thanks for your feedback. JP. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Fri, May 16, 2014 at 11:30:15AM +0200, Jean-Pierre Ledure wrote:
On 15/05/2014 12:30, Lionel Elie Mamane wrote:
one might hope that when loading the library, one source is
always preferred over the other.
After a test the behaviour of LibreOffice is found sane: when installing an
extension with the same name as a pre-installed one, the extension gets
INSTALLED but cannot be ENABLED.
So the pre-existing one keeps the precedence.
I took a deeper look at it; actually, the problem is different. A
user-installed extension *is* allowed to override a Basic script (or
dialog) library from a *bundled* *extension*, or from a *system*
(installed as for all users) extension. *But* not to override a
script (or dialog) library that forms an integral part of
LibreOffice. And access2base is (in LibreOffice 4.2) not a bundled
extension, but a standard part of LibreOffice.
The code that enforces that is:
desktop/source/deployment/registry/script/dp_script.cxx around line 350:
if
(sOriginalUrl.match(vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE)
||
sOriginalUrl.match(vnd.sun.star.expand:$UNO_SHARED_PACKAGES_CACHE)
||
sOriginalUrl.match(vnd.sun.star.expand:$BUNDLED_EXTENSIONS))
{
xScriptLibs-removeLibrary(rName);
bCanAdd = true;
}
else
{
bCanAdd = false;
}
However, if I direct the code flow into the if branch anyway with gdb,
then everything goes well, the built-in access2base is disabled and
the one from the user-installed extension takes over.
So, the question is why does this code enforce this condition, and
can we change it? Can we just remove the condition altogether, or
should we add this case:
|| sOriginalUrl.match($(INST))
Noel? Uray? You are our Basic FindTheExperts. What's your opinion on
this?
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Wed, May 14, 2014 at 08:18:51AM +0200, Jean-Pierre Ledure wrote: On 13/05/2014 10:13, Lionel Elie Mamane wrote: I presume it is compliant with the LO release policy to push the same patch also to the LO 4.2 branch ? I don't think so; no new features, only bugfixes. Can't an installation as extension override the bundled one, or something like that? I don't see how: installing the extension on LO 4.2 makes that 2 Basic libraries with the same name are present either in My macros or in LibreOffice macros. To be used a library must first be loaded by giving its (presumably unique) name ?? Yes, but one might hope that when loading the library, one source is always preferred over the other. With some luck, My Macros Dialogs will always be preferred to LibreOffice Macros Dialogs. But maybe we are unlucky and it is other way round. (I think in general both ways make sense, as long as the choice is made consistently; some scenarios favour priority to My Macros, other scenarios favour priority to LibreOffice. By luck I mean LibreOffice Basic was designed with the choice that suits our current scenario.) The result is LO being unstable or corrupt. As in you tried and bad things happen? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On 13/05/2014 10:13, Lionel Elie Mamane wrote: I presume it is compliant with the LO release policy to push the same patch also to the LO 4.2 branch ? I don't think so; no new features, only bugfixes. Can't an installation as extension override the bundled one, or something like that? I don't see how: installing the extension on LO 4.2 makes that 2 Basic libraries with the same name are present either in My macros or in LibreOffice macros. To be used a library must first be loaded by giving its (presumably unique) name ?? The result is LO being unstable or corrupt. JP. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Access2Base - New release
On Sun, May 11, 2014 at 03:37:28PM +0200, Jean-Pierre Ledure wrote: A new release of the Access2Base library (V1.1.0) has been pushed to master. https://gerrit.libreoffice.org/9303 Let's say will be soon :) Its main purpose is to get rid of the previous limitations: (...) Additionally the OpenDatabase method allows dynamic data access (...) These look like cool new features. Now my question. Soon all users of AOO and of LO 4.1 or before will benefit of the new version by downloading it from their respective extensions download centers. I presume it is compliant with the LO release policy to push the same patch also to the LO 4.2 branch ? I don't think so; no new features, only bugfixes. Can't an installation as extension override the bundled one, or something like that? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
