Mac builds / lang-packs ...

l10n
#21

Hi,

       So - thus far we have:

       Norbert, Thorsten and
       Nguyen Vu Hung & Martin Srebotnjak

       pro this, and you against it. So - looking at your rational:

maybe I did not make myself clear.

I do not like the current "help must be separate pack" concept at all.
Especially since the online help does not work in different languages as it
should on the launch of such a big change.

Even when it will work (hopefully in 3.3.2), like Christian, I believe help
is a constitutive part of an office suite, just like the printing and
importing/exporting module etc. Noone thought of separating that (well, it
does not take as much space on disk as help, I guess).

So I would prefer it to be done the OOo way - full language builds (gui and
help), i.e. Spanish, Slovenian, English build etc. If LO has problems with
infrastructure, then different lang teams could maybe provide hosting space
for their language builds.

If that is not possible, my next vote goes for full-all-language-build (with
all-language gui and help).

Lp, m.

#22

Martin Srebotnjak wrote:

Even when it will work (hopefully in 3.3.2)

It should work even in 3.3.1

So I would prefer it to be done the OOo way - full language builds (gui and
help), i.e. Spanish, Slovenian, English build etc. If LO has problems with
infrastructure, then different lang teams could maybe provide hosting space
for their language builds.

This is much more than just hosting space (and I believe you mean
'mirror space' here), it's also backup space, time to produce
builds, time to upload builds, time to distribute builds to mirrors
- all of that increases by an order of magnitude with full lang
builds. Plus, it's such a waste - 95% of the bits are the same.

I don't currently see any way around the current approach, for
official TDF releases, if we want to keep the current agility.

Cheers,

-- Thorsten

#23

Hi Christian,

2011.02.09 00:44, Christian Lohmaier rašė:

2011.02.08 22:32, Christian Lohmaier rašė:

2011.02.08 18:18, Christian Lohmaier rašė:

2011.02.08 17:46, Christian Lohmaier rašė:

* You cannot install as regular user (you always have to identify as
administrator)
(authentication is done before being able to select a
target-directory)

[...]

I did, believe me.

What about the second drop-down here:
http://s.sudre.free.fr/Stuff/PM102_4.jpg ?

Look at it for a few seconds, and think about it yourself for a while.
There is *no* choice "ask for permissions when necessary".

The thing is – I don't see the other options in the drop-down.

http://developer.apple.com/tools/installerpolicy.html

Thanks.

As I understand it, the admin users would not be getting the password prompt if this option is set to Admin Authorization. Others would be getting it. IMO, that's a fair enough trade considering that the installer would only allow to choose the installation disk, and not directory (which means that /Applications/ in the main disk is the most likely location, and it would need authorization anyway).

IMO, it's not such a big problem indeed.

But I
remember reading yesterday (or maybe the day before it) that that checkbox
is there to enable/disable the password prompt.

Yes, but then you don't get any, even when it would require a
password/administrator privileges, and then the installation will
fail.

Which is why Admin authorization is probably the best option.

copying an app from dmg is completely different from the installer
package we're discussing here.
And yes, it *does* ask for administrator privileges, when a non-admin
user tries to copy files into /Applications folder.
If you only got one user account, you probably don't notice, since
that user is administrator by default.

Yep, that's obviously my case. :slight_smile:

The permissions /are/ necessary, but you don't have to deal with them
when creating the bundle (the drag'n'drop "installer"), since it's
regular copy operation and Mac OS X takes care of it and asks for
privileges when necessary.

Such a thing is not possible with the "package installer", there the
one who builds the installer has to decide *beforehand* what
privileges the installer will ask for.
If you want the user to be able to install to /Applications, you have
to require administrator privileges. But then a user who is not
administrator, and doesn't have access to an administrator account to
fulfill that requirement cannot install at all, even if the installer
would offer a target-folder selection, since the user doesn't even get
past the authorization.

How often is that the case?

So when you want to test yourself, create a non-administrator user first.

Not necessary. The installer asked me for my password even though I am an admin. It also asked me to provide my password even when I chose to install the package into my home directory, how lame is that!

Well, it seems like my expectations for it were a bit higher. Basically, it looks like an incomplete product. Perhaps we could write our own installer plugin which would check itself whether elevation is needed or not, and then expect those who install using commandline to just use sudo, but that's probably not really worth the trouble...

Rimas

#24

2011.02.09 01:13, Martin Srebotnjak rašė:

Hello,

just for the sake of this discussion, how big is the MSO installation for OS
X? Maybe someone can check, I am not using it.

If LO dmg will grow to 350Mb or 400Mb (with help in all languages) probably
that is still not so bad compared to the full dmg of MSO.

I understand not everyone has fast internet access and some people voice
their concern about it but is there really a difference between 150Mb and
250Mb dmg? Do/can people in countries with very slow internet access really
buy MacPros, MacBook Pros, iMacs etc.?

I mean, probably even 150Mb is too much for those using very slow internet
access, they would need an app in the range of 10-50Mb and not 200Mb.

In that case LO should do something about the hard-copy distribution of LO -
DVD's with LO should be available from local shops in those countries with
lower-band internet, I guess. This project could lead the way:
http://web.libreofficebox.org/

I just hope other languages don't get forgotten (as they got with the
Portable LibreOffice which TDF members now claim TDF has nothing to do with
it although it is hosting its files).

LibreOfficeBox is similar, by the way – AFAIK, it's gonna be a German-only DVD mirrored worldwide... The reasoning is simple though – being a volunteered product, it features what its creators want it to, and since they all speak German, they chose to add a few other products to the DVD instead of other languages.

Re hardcopy distribution: I think it could be even easier:
a) we could contact local magazines about shipping LibO CD's/DVD's with a few of them
b) we could take the Ubuntu approach and ship bigger amounts of those disks to local volunteers who could then give/mail them out locally.

Re downloading big files: I suggested some time ago to implement the ability in the installer to fetch needed files from the Internet. However, nobody volunteered to invest their time into this (that includes myself), so we have what we have now.

Rimas

#25

Hi Rimas, *,

2011.02.09 00:44, Christian Lohmaier rašė:

2011.02.08 22:32, Christian Lohmaier rašė:

As I understand it, the admin users would not be getting the password prompt
if this option is set to Admin Authorization. Others would be getting it.
IMO, that's a fair enough trade considering that the installer would only
allow to choose the installation disk, and not directory (which means that
/Applications/ in the main disk is the most likely location, and it would
need authorization anyway).

No, OOo/LO can be installed into any directory, there is no artificial
limitation on where to put it. This is a huge benefit.

IMO, it's not such a big problem indeed.

Well, I completely disagree, especially for testers it is very
important to be able to install multiple versions side by side and in
an easy way. And very often those have dedicated playground/testing
accounts to not conflict with the rest of the system, and obviously
those users don't have administrator privileges. So changing the
installer type would be a pain in the a*.

[...]

So when you want to test yourself, create a non-administrator user first.

Not necessary. The installer asked me for my password even though I am an
admin. It also asked me to provide my password even when I chose to install
the package into my home directory, how lame is that!

What installer please? There is no package installer that would ask
for a passworf for LO. (and never was). Opening the dmg-bundle and
using drag'n'drop surely doesn't ask when using a target directory
where you have regular write-access.

ciao
Christian

#26

Hi,

2011.02.09 17:43, Christian Lohmaier rašė:

As I understand it, the admin users would not be getting the password prompt
if this option is set to Admin Authorization. Others would be getting it.
IMO, that's a fair enough trade considering that the installer would only
allow to choose the installation disk, and not directory (which means that
/Applications/ in the main disk is the most likely location, and it would
need authorization anyway).

No, OOo/LO can be installed into any directory, there is no artificial
limitation on where to put it. This is a huge benefit.

I'm talking about installers produced by PackageMaker. The only "change location" possibility I found in an installer quickly produced for me by PackageMaker was a possibility to select from:
1) Installing the package to my user only (homedir?)
2) Installing it for all users (root folder, I guess ?)
3) Choosing a target disk (but not the directory!)

And that's the biggest set of target options that I could get. I had to enable all of them separately in the PackageMaker.

[...]

So when you want to test yourself, create a non-administrator user first.

Not necessary. The installer asked me for my password even though I am an
admin. It also asked me to provide my password even when I chose to install
the package into my home directory, how lame is that!

What installer please? There is no package installer that would ask
for a passworf for LO. (and never was). Opening the dmg-bundle and
using drag'n'drop surely doesn't ask when using a target directory
where you have regular write-access.

Well, I made myself a dummy installer that "installed" a single document for me. :slight_smile:

Rimas

#27

Maybe strange idea and not thought to an end:

allow people to do their own builds and distribute those via our mirror network (or a parallel mirror network .. or their own network or whatever :slight_smile: )
This would be similar to mozilla's contrib builds.

So - the TDF "core build team" takes care about the general builds (multilang + helppacks + langpacks in some cases). l10n teams (or teams porting to other platforms) take care about "what they want to have". With this the core team will not have to deal with the additional build and upload time, contributed builds can be de-coupled from regular builds (might be published some days later, announced locally only ...).

regards,

André

#28

André Schnabel wrote:

allow people to do their own builds and distribute those via our
mirror network (or a parallel mirror network .. or their own network
or whatever :slight_smile: )

Hi Andre,

well when using our current mirror network, we run into the
mentioned speed, size & backup issues. The other suggestions: sure.

Actually, that's what a few people already do, FWICT. :slight_smile:

Cheers,

-- Thorsten

#29

Hi Martin,

If LO dmg will grow to 350Mb or 400Mb (with help in all languages)

  So - in fact, we can compress the per-language help content down to
around 1.5Mb of real content (with some lifting); That would still mean
another +80Mb or so to have every languages' help bundled which seems a
bit too much.

  HTH,

    Michael.