Download it now!
Bug 43785 - Provide Binaries in tar.gz Format
Summary: Provide Binaries in tar.gz Format
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Installer-Linux
  Show dependency treegraph
 
Reported: 2011-12-13 03:29 UTC by Luca Cappelletti
Modified: 2018-09-30 15:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Cappelletti 2011-12-13 03:29:08 UTC
The need of change from rpm to generic tar.gz
LibreOffice suffer from the OO/Suse/rpm chain to spread the software but today Debian/Ubuntu/.deb are the real path so there no more reason to provide rpm based packaging.

I propose to return to generic tar.gz archive and let distributors to customize with their own packaging technologies.

I found very usable the way Mozilla.org provide Firefox packaging using only a tar.gz where you just unarchive and run direct (Distributors then provide the specific package).

It's totally unusable for a generic people to download and run LibreOffice because require you to -install- the rpm in case of an rpm distribution or convert with alien and install in case of .deb based distribution or...nothing else.

When you go to the Mozilla.org website and download Firefox you'll end up with a tar.gz that you can just extract where you want and start there.Thisi is far easy then the actual rpm way (masked into a tar.gz).

For now no installer please, just an archive to open and play inside.

The use of rpm today it's not neutral.

bye
L
Comment 1 Miklos Vajna 2012-02-26 03:49:56 UTC
FWIW, rpm is just another container, so you can install it almost the same way as a Mozilla .tar.gz. You need something like:

rpm --dbpath /foo/.RPM_OFFICE_DATABASE --query -a
rpm --upgrade --ignoresize --nodeps -vh --relocate /opt=/foo/opt --dbpath /foo/.RPM_OFFICE_DATABASE RPMS/*.rpm

If you want to extract the contents of the rpms (it works as a user!) to /foo.

(Anyway agreed, it's hard to imagine that on Linux one replaces the distro packages with these universal binaries, so a simple .tar.gz would make sense -- IIRC it's even possible to do that, just that result is not provided ATM. Check the mingw binaries, there you get a .tar.gz already.)
Comment 2 Jiehong 2012-03-20 08:57:41 UTC Comment hidden (me-too)
Comment 3 sasha.libreoffice 2012-04-30 02:23:59 UTC
From one hand, situation where we have archive with much rpms is not very handy. Suppose, we want to install 32 and 64 bit version at once.

From other hand, we can move /opt/libreoffice to another place after installing. It should work.
Comment 4 Thomas Hackert 2012-09-29 12:03:06 UTC
Hello Luca, *,
I think, this is a feature request, not a bug., soI have changed this under "Importance". If you think, I am wrong, feel free to change it back ... ;)

Now to your "bug": I think, it would be nice to provide LO as binary packages, but not only as them. I am of the opionion, that we should provide LO as rpm/deb packages as well for people, who prefer that format ... ;)

IIRC, it is planned to provide pre-builds (betas, RCs and the like) as binary packages, but I am not sure, when this will happen, sorry ... :( But maybe this leads to the knowledge, how to build binary packages in a fast and easy way ... ;)
HTH
Thomas.
Comment 5 Luca Cappelletti 2012-10-01 08:35:48 UTC
Thank you all for your comments.

My opinion is that when LO is released as specific binary should be provided in a relocable folder packed with the universal tar.gz archive.

I expect to do a simply:

tar -xf LO.tar.xf
then
cd LO and
./soffice

this is the way I mean "more usable"
At the moment I simply expand .deb and relocate under a personal folder...it works very well...but it's not so usable as I mean...(you need to know how to dpkg that is platform specific, tar.gz is universal instead)

But after all, thank you for your patient to answer me,

bye

L
Comment 6 Joel Madero 2013-05-15 05:15:46 UTC
Due to comment 1 and comment 4, I'm marking this as NEW and agreeing that it's an enhancement request, not a bug.

Lowering to low priority as it's clear not much demand, over the course of 17 months we have really only the OP asking for it, a couple triagers have confirmed the request but outside of that, no duplicates reported, no additional input from users.

Thanks for the request Luca! Apologies that it sat unconfirmed so long
Comment 7 Urmas 2013-05-15 07:59:36 UTC Comment hidden (no-value)
Comment 8 Joel Madero 2013-05-15 13:49:50 UTC Comment hidden (off-topic)
Comment 9 Alex Thurgood 2015-01-03 17:39:26 UTC Comment hidden (no-value)