Access2Base - New release

[Lionel Elie Mamane]

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