Bug 838520 - Move zeitgeist support to a subpackage
Move zeitgeist support to a subpackage
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: totem (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On: 861715 861754
Blocks: depchain
  Show dependency treegraph
 
Reported: 2012-07-09 06:46 EDT by Thorsten Leemhuis
Modified: 2016-04-08 13:00 EDT (History)
15 users (show)

See Also:
Fixed In Version: totem-3.20.0-2.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-08 13:00:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch against totem 3.8.0-1 spec (2.62 KB, patch)
2013-04-01 10:16 EDT, Christoph Wickert
no flags Details | Diff

  None (edit)
Description Thorsten Leemhuis 2012-07-09 06:46:51 EDT
Description of problem:
totem-3.4.3-1.fc17 has a new dep on libzeitgeist from this spec file change
http://pkgs.fedoraproject.org/gitweb/?p=totem.git;a=commitdiff;h=41a61d22db537199384f705327c7ce6c7fb1152b

That itself afaics is fine, but the current libzeitgeist in F17 has a hard dep on the zeitgeitst daemon:

$ sudo rpm -q libzeitgeist-0.3.18-1.fc17 --requires  | grep zeit
zeitgeist  

Hence yum installs zeitgeist when updating to totem-3.4.3-1.fc17. Is that really wanted? I guess some people won't like that. 

Or am I missing something?
Comment 1 Kalev Lember 2012-07-13 20:23:30 EDT
If you think that libzeitgeist shouldn't depend on the zeitgeist daemon, perhaps the best way to move forward is opening a ticket against libzeitgeist?
Comment 2 Thorsten Leemhuis 2012-07-18 16:30:22 EDT
(In reply to comment #1)
> If you think that libzeitgeist shouldn't depend on the zeitgeist daemon,
> perhaps the best way to move forward is opening a ticket against
> libzeitgeist?

Maybe this whole dep chain is worth it? I don't know (but I doubt it, that's why I'm here). 

And if someone more familiar with the issue finds out that libzeitgeist shouldn't depend on the zeitgeist that it won't be something that will be changed immediately and hence should be tracked in a separate bug to avoid confusion.
Comment 3 Craig Barnes 2012-08-02 13:32:07 EDT
I've just removed totem from my system because of this. It's not really reasonable for a media player to depend on a library resembling spyware.
Comment 4 Craig Barnes 2012-08-02 14:13:45 EDT
This is perhaps the wrong place, but could I also request that the Zeitgeist plugin itself be moved to a separate totem sub-package? I know it doesn't fix the dep chain issue but Zeitgeist is a genuine privacy/security concern and IMHO has no place being in the default set of plugins, whether enabled or not.
Comment 5 Kalev Lember 2012-08-02 15:14:31 EDT
One way to break this dep chain would be to remove 'Requires: zeitgeist' from the libzeitgeist package. Usually when a split between a daemon / library package is done, it's precicely for this reason to allow linking with the library without dragging in the daemon.

Also, in the libzeitgeist new package review ticket [1], Michael Schwendt pointed out the possibly unwanted 'Requires: zeitgeist', but looks like the package owner missed this comment.

Reassigning the ticket to libzeitgeist for opinions.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=674188#c2
Comment 6 Renich Bon Ciric 2012-08-02 18:31:47 EDT
(In reply to comment #4)
> This is perhaps the wrong place, but could I also request that the Zeitgeist
> plugin itself be moved to a separate totem sub-package? I know it doesn't
> fix the dep chain issue but Zeitgeist is a genuine privacy/security concern
> and IMHO has no place being in the default set of plugins, whether enabled
> or not.

I think this solution will enable the user not to install zeitgeist and have totem at the same time.

What is the purpose of depending on libzeitgeist if it's not to be used?

I am open to removing the zeitgeist dependency from libzeitgeist if general consensus is reached. But this is, IMHO, ridiculous since the library's purpose is to access zeitgeist.
Comment 7 Craig Barnes 2012-08-02 21:15:16 EDT
(In reply to comment #6)

I think you misunderstood what I meant. I want to be able to install totem and have neither libzeitgeist nor zeitgeist pulled in as dependencies. I was suggesting moving libtotem-zeitgeist-dp-plugin.so and zeitgeist-dp.plugin out of the totem.spec %files section and into a sub-package, say "totem-zeitgeist".

The build time dependencies would stay the same but totem's runtime dependency on libzeitgeist would move into totem-zeitgeist, meaning people who just want to use totem but couldn't care less about zeitgeist don't have to worry about things like this.

It still doesn't fix the dep chain issue being discussed here but it does remove all traces of zeitgeist from the totem base package.

I've just tried patching totem.spec and rebuilding and it all works as expected.
Comment 8 H. Peter Anvin 2012-09-30 00:49:02 EDT
Zeitgeist is one of the most egregious invasions of users' privacy imaginable... I just found out that Zeitgeist had been installed *and activated* on my system without my consent through the above path...

I would consider this to be a security-level bug.
Comment 9 Christoph Wickert 2012-09-30 04:53:24 EDT
If people think this is a problem is not in totem but in libzeitgeist, they should bring this issue up and not just reassign this bug.

I agree that the zeitgeist dependency of libzeitgeist is bad and have therefor filed bug 861715. But this is only part of the problem.

1. This update MUST NOT not have happened in a stable release because it was a violation of our update policy. Quoting: https://fedoraproject.org/wiki/Updates_Policy#Philosophy:
"Rebases should be carefully considered with respect to their dependencies. [...]
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates."

2. As compiling against libzeigeist adds no benefit without the zeitgeist deamon, totem maintainers should consider a totem-zeitgeist subpackage for the zeitgeist-plugin. This subpackage can then have a dependency on the zeitgeist, too.

Because of these two I reassign this bug to totem. libzeigeist will be dealt with in bug 861715.


(In reply to comment #6)
> I am open to removing the zeitgeist dependency from libzeitgeist if general
> consensus is reached. But this is, IMHO, ridiculous since the library's
> purpose is to access zeitgeist.

libmysqlclient is used to access mysql, but the mysql-libs package doesn't depend on mysql-server. Same for openldap and many others. client side libraries should never depend on daemons.
Comment 10 Christoph Wickert 2012-11-03 12:05:26 EDT
The immediate problem was solved with an update for libzeitgeist that drops it's dependency on zeitgeist (see bug 861715), however I think the proper fix is to move the plugin to a totem-zeitgeist package that would then also require zeitgeist.
Comment 11 Christoph Wickert 2013-04-01 10:16:22 EDT
Created attachment 730283 [details]
Patch against totem 3.8.0-1 spec

Bastien, please review this patch and apply it if you think it's suitable.
Comment 12 Fedora End Of Life 2013-07-03 16:38:46 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2013-12-21 03:39:28 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Fedora End Of Life 2015-05-29 04:45:47 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Fedora Update System 2016-04-05 07:39:02 EDT
bijiben-3.20.0-2.fc24 totem-3.20.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f6ff99ebd8
Comment 16 Fedora Update System 2016-04-06 13:54:09 EDT
bijiben-3.20.0-2.fc24, folks-0.11.2-5.fc24, totem-3.20.0-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f6ff99ebd8
Comment 17 Fedora Update System 2016-04-08 13:00:39 EDT
bijiben-3.20.0-2.fc24, folks-0.11.2-5.fc24, totem-3.20.0-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.