basically this already exists, on any GNU/Linux system you can use the "install" script included in the RPM instset to install in any directory, no root privileges required.

Yes for users comfortable with the commandline, running the "install" script only bundled in the RPM installer .tar.gz would suffice their needs, but it wont help novice user of linux (likely someone who is moving over from windows) who only knows/uses the GUI.

Seems this will be solved with Flatpak.

http://www.libreoffice.org/download/flatpak/

(In reply to Yousuf (Jay) Philips from comment #3)
> Seems this will be solved with Flatpak.
> 
> http://www.libreoffice.org/download/flatpak/

Flatpak is nice and is an alternative distribution system, but I do not think it's just a portable application, as it could be a *.bin file or an AppImage file (sandbox, work in progress).

Anyway, I think it was a good decision.

Is there any plan to distribute Still and Fresh versions separately?


Thanks

(In reply to Bastián Díaz from comment #4)
> Flatpak is nice and is an alternative distribution system, but I do not
> think it's just a portable application, as it could be a *.bin file or an
> AppImage file (sandbox, work in progress).

Yes i guess you are right that flatpak doesnt make it a portable application as you cant place a flatpak on a usb run the app on any distro you want, though one of the primary benefits of the portable app is to be able to run an app that bundles all it libraries together with the app so that i can run even if the packages arent installed on a system, which flatpak does do.

> Is there any plan to distribute Still and Fresh versions separately?

From what i've seen, it will only be for Fresh.

Was digging through the appimage collection and see they have appimages for Fresh and Dev.

https://bintray.com/probono/AppImages/LibreOfficeDev/view

Contacted the author of appimage ( https://github.com/probonopd/AppImages/issues/63 ) and he said, "Might be worth mentioning that the script to generate the AppImage is really easy and is available here:
https://github.com/probonopd/AppImages/blob/master/recipes/libreoffice/Recipe
 So they could basically just take it and integrate it into their workflow."

(In reply to Yousuf (Jay) Philips from comment #6)
> Contacted the author of appimage (
> https://github.com/probonopd/AppImages/issues/63 ) and he said, "Might be
> worth mentioning that the script to generate the AppImage is really easy and
> is available here:
> https://github.com/probonopd/AppImages/blob/master/recipes/libreoffice/Recipe
>  So they could basically just take it and integrate it into their workflow."

Yeah, I know. I have seen Probono promotes AppImage in places where there is talk of Flatpak 😅...

However, I think AppImage and Flatpak are very different approaches and technologies that are not competing with each other.

LibreOffice already offers a "portable" way through a scrip installation which makes things easier, however, LO Developers want to offer another portable alternative?

If the answer is positive, AppImage would be a good generic Linux package to replacement *.rpm and *.deb packages currently offered by TDF (each distribution maintainers offer it anyway). Promote the use AppImage in software stores help greatly improve the user experience when installing this type of package for the end user, but anyway, it is more easier to use the installation script currently offered in LibreOffice. 

A distribution system for Linux users using: source code (basic) + Generic AppImage (Portable) + Flatpak (Advanced and Cool) is simple and always keep the software updated by TDF.

I don't see the need for a linux portable version, as you can always just extract the rpms using e.g. 

for i in *.rpm; do rpm2cpio $i |cpio -idmv; done

and then launh LO from the opt/program/libreoffice dir - if you really want to leave no traces, you pass another  env:UserInstallation parameter or edit bootstrap.rc in the extracted hierarchy.

so portable version is easy to accomplish - extract, modify the bootstrap.rc re userprofile and you're done.

flatpak goes a similar route, by isolating the app agains other stuff, but is not really what  I'd call portable...

(In reply to Christian Lohmaier from comment #8)
> I don't see the need for a linux portable version, as you can always just
> extract the rpms using e.g. 
> 
> for i in *.rpm; do rpm2cpio $i |cpio -idmv; done
> 
> and then launh LO from the opt/program/libreoffice dir - if you really want
> to leave no traces, you pass another  env:UserInstallation parameter or edit
> bootstrap.rc in the extracted hierarchy.
> 
> so portable version is easy to accomplish - extract, modify the bootstrap.rc
> re userprofile and you're done.

Do you think that all users have advanced knowledge of Linux distributions? If so, this problem would not exist Bug 80941

A user initiates Linux or are migrating from Windows or OS X expects an easy way to install and update your software. That would help greatly improve the user experience.

> flatpak goes a similar route, by isolating the app agains other stuff, but
> is not really what  I'd call portable...

I agree with you, but with a little promotion in the future a Flatpak package can be installed with a few clicks.

the point is not about a linux version in general, but about a portable version. Why would you need a portable version of LibreOffice for linux? Chanches are that if you're using linux, you can just launch LibreOffice that's part of the default desktop-installation.

If you're going elsewhere, and they happen to have linux installed, but not LibreOffice, that'd be pretty rare (and as alternative you can have a live-USB distro with all included)

if unpacking LO is to complicated, you can use the script Michael mentioned.

Again: I see no point in offering something where the only change is a different value for userprofile in bootstraprc 

users like in Bug 80941 should just use LibreOffice as provided by their distribution.

Users want to use the latest version on Linux without requiring to go to the terminal and try to fix dependency hell.  They simply want to fetch the latest version from http://www.libreoffice.org and get it executed by clicking on the downloaded file from a GUI file manager to get it installed and/or executed.

Distributions do not always provide the latest versions.

Apply any arguments used to provide a portable Windows/Mac version to Linux.  It is for the same reasons; convenience.

that has no relation to a portable version. You can install LO provided by TDF without dependency hell. If you already had LO, you can install update. Even if you never had LO installed, the baseline of TDF provided builds is so low that the requirements will always be met.

Users in that case most definitely also *DON'T* want a portable version. As a portable version would come without any system integration, no startmenu items, no filetype associations.
Please don't mix issues.

(In reply to Christian Lohmaier from comment #10)

I see that you have not answered my question is it has nothing to say about it?

> the point is not about a linux version in general,

Again Bug 80941

> but about a portable
> version. Why would you need a portable version of LibreOffice for linux?
> Chanches are that if you're using linux, you can just launch LibreOffice
> that's part of the default desktop-installation.
> 

As already mentioned, not always has the latest LO update (still or fresh) in default packages included in the distribution. This is a problem in general and is not always possible to install the latest version from the web due to dependency problems. I think in this case, a portable version using AppImage is a good solution.

> If you're going elsewhere, and they happen to have linux installed, but not
> LibreOffice, that'd be pretty rare (and as alternative you can have a
> live-USB distro with all included)
> 

It is not the real problem

> if unpacking LO is to complicated, you can use the script Michael mentioned.
> 

We return to the problem of usability/UX and availability in only two types of packet format

> Again: I see no point in offering something where the only change is a
> different value for userprofile in bootstraprc 
> 

...

> users like in Bug 80941 should just use LibreOffice as provided by their
> distribution.

Wow... See above

(In reply to Christian Lohmaier from comment #12)
> that has no relation to a portable version. You can install LO provided by
> TDF without dependency hell. If you already had LO, you can install update.
> Even if you never had LO installed, the baseline of TDF provided builds is
> so low that the requirements will always be met.
> 

The list of reports for distribution would be too long to put here, but it is a reality that LibreOffice maintainers can not always keep the last update for dependency problems.

> Users in that case most definitely also *DON'T* want a portable version. As
> a portable version would come without any system integration, no startmenu
> items, no filetype associations.
> Please don't mix issues.

I think you should learn more ... do you know the technologies that have been spoken here as a portable solution for LO? 

Well, as much as Flatpak and AppImage not lose integration with the system.

Please, now you can easily test both:
• https://www.libreoffice.org/download/flatpak/
• https://bintray.com/probono/AppImages/LibreOffice/view
  https://bintray.com/probono/AppImages/LibreOfficeDev/view

*THIS* is about portable, continuing ramblings about *OTHER* bugs won't change anything.

And you can write bullshit about "dependency problems" as much as you want, but fact is that LibreOffice as provided by TDF doesn't have any external dependencies that would cause problems on any Linux distro.

And furthermore: A portable version would have the very same dependencies.

If you want a different way to install LibreOffice, you're commenting *ON THE WRONG BUG*!

(In reply to Christian Lohmaier from comment #15)
> *THIS* is about portable, continuing ramblings about *OTHER* bugs won't
> change anything.
> 

Both reports are closely related and may be unique solution. A portable application improves the user experience obtaining the latest version, installation/update of software using new technologies. 
If you do not understand the relationship of both issues it is not my problem.

> And you can write bullshit about "dependency problems" as much as you want,
> but fact is that LibreOffice as provided by TDF doesn't have any external
> dependencies that would cause problems on any Linux distro.
> 

Come on... You said that if a user requires easy installation of LibreOffice, should use the methods provided by each distribution. The problem is that distributions do not always offer the latest versions of LibreOffice for technical reasons ... is not bullshit as you say and does not solve the problem.

On the other hand, TDF only provides binaries are packaged in two formats and installation is not very intuitive for the end user. A portable binary solves this problem, in addition to use in other more exotic places, such as a flash drive or external HDD.

> And furthermore: A portable version would have the very same dependencies.
> 

Of course, no one disputes that point. However, a package like AppImage or Flatpak includes the necessary dependencies to run even on very old systems and multiple distribucione easily.

> If you want a different way to install LibreOffice, you're commenting *ON
> THE WRONG BUG*!

Sorry, here we are discussing the feasibility of using a portable version of LibreOffice for Linux user. By definition, a portable application is one that can be run without prior installation, easy run and "portable".

LibreOffice developers have already chosen alternative installation system for Linux user using Flatpak. Now the point of discussion is whether Flatpak is "portable", I think not and you seem to agree.

removing myself from this bug.

Feel free to add me on another one that  actually is about portable version and has convincing reasoning to back up a request for it.

I'll adress Christian's "Why would you need a portable version of LibreOffice for linux?"
I do because I am stuck with a certain version of a certain distribution (due to compatibility with a proprietary software). Therefore can't update for example glibc to be compatible with current LO versions (or Flatpak for that matter). Nontheless, I'd very much like to use a current LO.
Another scenario would be users without adminstrator rights. Or users who just want to check whether the environmental upgrades required for a current LO version would be worth the hussle.

Christian's suggestion "for i in *.rpm; do ..." doesn't help in any of those cases, even if the user would be of the elite kind that actually understood what this line does, and also would be able to figure that out on their own.

I'm a translator of LibreOffice and use gnu/linux.
For me, the most important thing to translate in my LibreOffice localized edition are the most noticeable strings in the UI. Sometimes parts of the menus and dialog boxes are translated while others are in English. 
In my opinion, a first impression of that sort, makes new users of LibreOffice reluctant to adopt or event start using LibreOffice. This is why it's a priority for me to translate those strings first.

When I was working on Windows I used the latest (Fresh) Portable MultilingualAll version to see what parts of the LibreOffice UI aren't translated yet in my localized edition, and then I would translate them.

Nowadays, on gnu/linux I have no simple way of doing so. I can install the latest version with flatpak and then update every time, but I don't want to install extra software on my production machine, and risk it. ("Avoid 10 fatal mistakes in Linux": "10. Do not experiment on a production machine, no matter how tempting it may be to try out something new").

I don't know which format (appimage/flatpak/snap) is better and has more capabilities, and frankly as someone who needs it only for improving the translation of his localized LibreOffice edition, I don't care. I just want a fast method (that doesn't leave any trace on my machine) of checking the latest localized edition and find untranslated strings that might cause new users of LibreOffice to reject the software.

I found unofficial appimages of LibreOffice, but they don't contain all the localized versions, i.e. they're not a multilingual version like the portable version for Windows. Please consider adding an appimage multilingual version of the latest version of LibreOffice (Fresh branch). I believe that other translators gain from this.

*edit/correction*
I believe that other translators will benefit from this.

So Antonio Faccioli‏ is building stable, pre-release and daily builds of libreoffice as mentioned here - https://twitter.com/Faccioli74/status/871654878287933443

http://libreoffice.soluzioniopen.com/

Daily builds can be converted to appimage with this script
https://github.com/AppImage/AppImageKit/wiki/Bundling-LibreOffice

Christian Lohmaier asked in comment #10:

> "Why would you need a portable version of LibreOffice for Linux?"

I'll give you my two major use cases:

1. I have more than one system, and I'm using different Linux distros
   on each of them. Also, I have multiple virtual machines which I boot
   up from time to time. I don't want to install LibreOffice on each of
   them separately (and also, each one would give me a different LO 
   version through their respective native package management system.

   Therefor I want run LibreOffice via a network share mounted on my
   currently active system, This would only work with a "portable
   version".

2. I want to run, evaluate, compare and debug multiple LO versions
   side by side, without messing with my system libraries.

   This works only with "portable versions" of LO.

If a Portable LibreOffice for Linux comes in the shape of an AppImage, it is super-easy for me to manage things, because I only have to deal with 1 single file for each LO version. If I have to manage complete directories, things start to become more complex...

So this is solved now with AppImages, which are hosted below.

http://libreoffice.soluzioniopen.com/

Great!  Thank you very much.  Any chance to have it made available on "https://www.libreoffice.org/download/download/" ?  Else, how is it expected for the casual user to find this version of LibreOffice and know it is safe, comes from a reliable source?

Appimage has a download page on the website, but it needs some minor tweaks to get it in order.

http://www.libreoffice.org/download/appimage/

But how does the casual, normal user, get to this page (http://www.libreoffice.org/download/appimage) from the home page (http://www.libreoffice.org)?  If you did not posted this link in this bug report, I would never have found out its existence.  https://www.libreoffice.org/download/download/ does not provide a link to the appimage version.

(In reply to Hans Deragon from comment #26)
> But how does the casual, normal user, get to this page
> (http://www.libreoffice.org/download/appimage) from the home page
> (http://www.libreoffice.org)?

Quite easily. When you click the 'Download' entry in the top menu of libreoffice.org, the menu that expands from it has 'LibreOffice as AppImage' as an entry.

Oh god.  I did not read the menu completely  I went directly to the 'Download LibreOffice' menu item, as it seams so natural to do so...

The problem is with the website menu.  I personally would have put everything on the main download page, or the menu should start with Linux Download, Mac Download, Windows Download, etc...

Ok, thanks for the portable version!

*** Bug 115684 has been marked as a duplicate of this bug. ***

Hi, 

thanks for providing an AppImage version. 

I just had opened a (duplicate) bug to propose using AppImage and did not realize that it is already offered, because it's not listed on the download-page at 

https://de.libreoffice.org/download/libreoffice-still/

Maybe wise to list the AppImage version on the download page. 

regards