Hey,
If you've ever used Sushi or GNOME Documents to preview an ODT document, you've probably noticed (or will soon notice) that strange GUI applications were installed after a recent F20 update: Chainsaw, LogFactor5, and LibreOffice Base. This is [1] and it's currently CLOSED WONTFIX.
I just want to draw some attention to this, since post-release dependencies impact the desktop team's ability to control the default set of applications. I'm pretty sure we don't want users to have these strange Java logging utilities by default.
On Tue, 2014-03-04 at 19:00 -0600, Michael Catanzaro wrote:
Hey,
If you've ever used Sushi or GNOME Documents to preview an ODT document, you've probably noticed (or will soon notice) that strange GUI applications were installed after a recent F20 update: Chainsaw, LogFactor5, and LibreOffice Base. This is [1] and it's currently CLOSED WONTFIX.
I just want to draw some attention to this, since post-release dependencies impact the desktop team's ability to control the default set of applications. I'm pretty sure we don't want users to have these strange Java logging utilities by default.
Thanks for bringing this up. I agree that such dependencies are a problem for what we are trying do.
On Tue, 2014-03-04 at 20:27 -0500, Matthias Clasen wrote:
On Tue, 2014-03-04 at 19:00 -0600, Michael Catanzaro wrote:
Hey,
If you've ever used Sushi or GNOME Documents to preview an ODT document, you've probably noticed (or will soon notice) that strange GUI applications were installed after a recent F20 update: Chainsaw, LogFactor5, and LibreOffice Base. This is [1] and it's currently CLOSED WONTFIX.
I just want to draw some attention to this, since post-release dependencies impact the desktop team's ability to control the default set of applications. I'm pretty sure we don't want users to have these strange Java logging utilities by default.
Thanks for bringing this up. I agree that such dependencies are a problem for what we are trying do.
FYI: David fixed this by removing the dependency of libreoffice-filters on libreoffice-base, and the update has reached F20 stable. Yay!
This means unoconv now depends on all the OTHER libreoffice programs, which is probably not great, but all of those are installed by default.
On Tue, Mar 04, 2014 at 07:00:15PM -0600, Michael Catanzaro wrote:
If you've ever used Sushi or GNOME Documents to preview an ODT document, you've probably noticed (or will soon notice) that strange GUI applications were installed after a recent F20 update: Chainsaw, LogFactor5, and LibreOffice Base.
Without the filters unoconv doesn't work at all(*) and users would need to hunt around for the appropriate packages to install. So the change fulfills an actual need. The proper fix is probably to seperate the file format reading code from the GUI apps and all the Java stuff but that's a long-term job for LO upstream to tackle.
Do you have a suggestion on how to improve unoconv packaging?
Looking at how similar cases (e.g. archiver frontends needing tar or gzip for their work) are handled throughout the repo doesn't show a clear pattern.
(*) I'm pretty sure it worked for your ODT case only because you happened to have lo-writer already installed.
On 5 March 2014 01:44, Lars Seipel lars.seipel@gmail.com wrote:
Do you have a suggestion on how to improve unoconv packaging?
Yes. Either split the GUI applications (the /usr/bin/binary and the .desktop file) as a separate subpackage or split off the libraries themselves as a -libs subpackage. Installing some addon for gnome-documents that installs two non-removable *ugly* applications in the software center is totally broken.
Looking at how similar cases (e.g. archiver frontends needing tar or gzip for their work) are handled throughout the repo doesn't show a clear pattern.
The analogy here would be if installing .zip support installed two ugly GUI apps. That's clearly not right, and if this isn't reverted in F20 I'll have no choice to blacklist the chainsaw and LogFactor5 applications from the software center.
Richard.
On Wed, 2014-03-05 at 08:18 +0000, Richard Hughes wrote:
The analogy here would be if installing .zip support installed two ugly GUI apps. That's clearly not right, and if this isn't reverted in F20 I'll have no choice to blacklist the chainsaw and LogFactor5 applications from the software center.
Will that do anything to solve the problem? That'd make it difficult for a user who actually wants those apps to find them, but the 99% of users who don't want those apps will still have them installed, correct?
I'm not sure those two apps are actually the problem, either. It's not their fault that another application (LibreOffice Base, I believe, which intentionally is not installed by default, but is now pulled in by unoconv) decided to depend on them. Base is the one I would blacklist if you must blacklist anything... but that doesn't help with the unoconv problem, either.
On Wed, 2014-03-05 at 09:33 -0600, Michael Catanzaro wrote:
On Wed, 2014-03-05 at 08:18 +0000, Richard Hughes wrote:
The analogy here would be if installing .zip support installed two ugly GUI apps. That's clearly not right, and if this isn't reverted in F20 I'll have no choice to blacklist the chainsaw and LogFactor5 applications from the software center.
I'm not sure those two apps are actually the problem, either. It's not their fault that another application (LibreOffice Base... decided to depend on them.
Base doesn't directly depend on them, they come from log4j and that is pulled in a number of extra levels down the dependency chain. By apache-commons-logging. Ideally packages could depend on the jars of log4j without getting those graphical apps along with it, i.e. split the log4j package.
C.
On Wed, 2014-03-05 at 08:18 +0000, Richard Hughes wrote:
On 5 March 2014 01:44, Lars Seipel lars.seipel@gmail.com wrote:
Do you have a suggestion on how to improve unoconv packaging?
Yes. Either split the GUI applications (the /usr/bin/binary and the .desktop file) as a separate subpackage or split off the libraries themselves as a -libs subpackage. Installing some addon for gnome-documents that installs two non-removable *ugly* applications in the software center is totally broken.
If we look at what's happening here, then the two applications in question that are showing up are both from the log4j package which is a dependency of (among others) apache-commons-logging which is a dependency of some other stuff which is a dependency of some other stuff which are dependencies of LibreOffice which is a dependency of unoconv.
I suggest the best place to solve this is in the *log4j* package and split that into two subpackages, one for the .jar (and whatever it needs to do it's work) on the assumption that that's the piece the dependents actually need, and another subpackage for the inspection/management graphical utilities.
caolanm->sochotni: Is it possible to split log4j like that ?
C.
desktop@lists.stg.fedoraproject.org
-
Caolán McNamara -
Lars Seipel -
Matthias Clasen -
Michael Catanzaro -
Richard Hughes