mozilla-mplayer unnecessarily depends on gecko browsers

I think it should be downgraded to recommendation, because installing both it's an absurd, working on it.

Merged from debian (version 3.45-1), downgraded to recommend and added xulrunner to recommend.

Personally, I don't think that www browsers should be made recommendations and not dependencies.
Let me quote the debian policy:

The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.

While:

The Recommends field should list packages that would be found together with this one in all but unusual installations.

Now, I hope you agree that to provide a significant amount of functionality for this plugin a www browser is needed?

Whether it makes sense or not to add xulrunner to the list of dependancies (or-ed!) its a matter of testing it.
For instance, I have not added it to gecko-mediaplayer yet (from the same upstream author) simply because I don't have any evidence that it will work.
Just the fact that it makes sense that it works is not enough (for instance gecko-mediaplayer should work with Opera and Konqueror, but it doesn't).
Can you perhaps test it and confirm if the mozilla-mplayer works with xul based applications (via xulrunner)?

Hi,

On Mon, Oct 29, 2007 at 11:47:24AM -0000, Cesare Tirabassi wrote:
> Personally, I don't think that www browsers should be made recommendations and
> not dependencies.
> Let me quote the debian policy:
>
> The Depends field should be used if the depended-on package is required
> for the depending package to provide a significant amount of
> functionality.
>
> While:
>
> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.
>
> Now, I hope you agree that to provide a significant amount of
> functionality for this plugin a www browser is needed?
>
> Whether it makes sense or not to add xulrunner to the list of dependancies
> (or-ed!) its a matter of testing it.
> For instance, I have not added it to gecko-mediaplayer yet (from the same
> upstream author) simply because I don't have any evidence that it will work.
> Just the fact that it makes sense that it works is not enough (for instance
> gecko-mediaplayer should work with Opera and Konqueror, but it doesn't).
> Can you perhaps test it and confirm if the mozilla-mplayer works with xul
> based applications (via xulrunner)?

I've tested it. It works.

Why should plugin-browser combinations have to be tested by package maintainers?
That just doesn't seem very fair to users that want to use a less popular
browser. They'll end up waiting a release or two before the dependencies will
be in their favor.

I guess it'd be nice if it could Depend: gecko-browser ...

-Forest
--
Forest Bond
http://www.alittletooquiet.net

So it can be added as Dependency with another |, so it's or a gecko browser
or xulrunner

On 10/29/07, Forest Bond <email address hidden> wrote:
>
> Hi,
>
> On Mon, Oct 29, 2007 at 11:47:24AM -0000, Cesare Tirabassi wrote:
> > Personally, I don't think that www browsers should be made
> recommendations and
> > not dependencies.
> > Let me quote the debian policy:
> >
> > The Depends field should be used if the depended-on package is required
> > for the depending package to provide a significant amount of
> > functionality.
> >
> > While:
> >
> > The Recommends field should list packages that would be found together
> > with this one in all but unusual installations.
> >
> > Now, I hope you agree that to provide a significant amount of
> > functionality for this plugin a www browser is needed?
> >
> > Whether it makes sense or not to add xulrunner to the list of
> dependancies
> > (or-ed!) its a matter of testing it.
> > For instance, I have not added it to gecko-mediaplayer yet (from the
> same
> > upstream author) simply because I don't have any evidence that it will
> work.
> > Just the fact that it makes sense that it works is not enough (for
> instance
> > gecko-mediaplayer should work with Opera and Konqueror, but it doesn't).
> > Can you perhaps test it and confirm if the mozilla-mplayer works with
> xul
> > based applications (via xulrunner)?
>
> I've tested it. It works.
>
> Why should plugin-browser combinations have to be tested by package
> maintainers?
> That just doesn't seem very fair to users that want to use a less popular
> browser. They'll end up waiting a release or two before the dependencies
> will
> be in their favor.
>
> I guess it'd be nice if it could Depend: gecko-browser ...
>
> -Forest
> --
> Forest Bond
> http://www.alittletooquiet.net
>
> --
> mozilla-mplayer unnecessarily depends on gecko browsers
> https://bugs.launchpad.net/bugs/137993
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
aka nxvl
Yo uso Software Libre, y tu?

I still would like to see some evidence.
If you can't do it yourself, you can also ask upstream, he is usually very responsive.

Hi,

On Mon, Oct 29, 2007 at 03:33:12PM -0000, Cesare Tirabassi wrote:
> I still would like to see some evidence.
> If you can't do it yourself, you can also ask upstream, he is usually very responsive.

Evidence of xulrunner/mozilla-mplayer compatibility? As I said, I have a
working application that does utilize the mplayer plugin. Were you looking for
further support of this claim?

-Forest
--
Forest Bond
http://www.alittletooquiet.net

Yes, that would be good.
It would also be cool if you could check with gnome-mplayer and gecko-mediaplayer, but the latter is not yet available in gutsy (actually, its not yet available in hardy too, but its just a matter of days).
I would really appreciate it.

Nicolas,

can you coordinate this with asac and/or fujitsu?
There could be also additional bugs they may want to fix with this update.

Thanks.

What would you like me to do to prove that mozilla-mplayer works with xulrunner?

I'm sorry, but I don't have time to test gnome-mplayer or gecko-mediaplayer.

-Forest

I have talk to upstream developer, and he answer to me and norsetto, we are now sure it work, thanks anyway.

I have talk to asac and fujitsu and both have answer they have no fixings for this new version, so this is the only one to do with the merge.

Then prepare a new merge with the agreed changes. Take into consideration that you should add appropriate links for the plugin dirs of xulrunner and xulrunner-1.9.
Please subscribe u-u-s when ready for upload.

Forest, can you provide us with a xulrunner app where we can test it?

I have talk to Ari Pollak, the Debian Maintainer, and he told me he will add those features in the next upstream release, which will be any day from now on, do we wait for it or make that patch anyway?

He also say it work fine without copying to any links for xulrunner or xulrunner-1.9, so i will test it with some help of Forest

Ok, so as Ari Pollak said he will patch this bug on the next release, which will be released any day from now on, i decided to wait, and only do the merge.

I don't think they have xulrunner-1.9 in debian, so lets wait for this and see what we get.
Just in case, asac told me that they are planning to use /usr/lib/xulrunner-addons/plugins/ for xulrunner(-1.9) plugins. Its not yet fixed, so we may have to wait for that as well.
Merge is uploaded (with rearranged changelog, please next time sort changes by affected files; I also had to change distribution from gutsy to hardy).
Thanks for your contribution!

Thanks, i will consider that for the changelog next time :D

Does this bug can be been resolved by Bug #193812?

I use swiftweasel and in order to keep firefox from my disk, I have to modify the dependencies. Please do not depend on any browser if this is possible. Or depend on some virtual packet.

Package: swiftweasel-prescott
Essential: no
Priority: optional
Section: web
Maintainer: stickk [<email address hidden>]
Architecture: i386
Version: 2.0.0.14
Replaces: swiftweasel-athlontbird, swiftweasel, swiftweasel-athlon64, swiftweasel-athlonxp, swiftweasel-k6, swiftweasel-k8, swiftweasel-nocona, swiftweasel-pentium2, swiftweasel-pentium3, swiftweasel-pentium3m, swiftweasel-pentium4, swiftweasel-pentium4m, swiftweasel-pentiumm, swiftweasel-athlon64-pango, swiftweasel-athlonxp-pango, swiftweasel-k6-pango, swiftweasel-k8-pango, swiftweasel-nocona-pango, swiftweasel-pentium2-pango, swiftweasel-pentium3-pango, swiftweasel-pentium3m-pango, swiftweasel-pentium4-pango, swiftweasel-pentium4m-pango, swiftweasel-pentiumm-pango, swiftweasel-prescott-pango
Depends: ttf-dejavu
Filename: pool/i386gutsy/swiftweasel-2.0.0.14_prescott_ubuntu-i386.deb
Size: 10007434
MD5sum: 899d727034a0e2373dfbd19492bf7b0c
SHA1: 215ba988a7d28b89ef6f087606efa28df95bfa6d
SHA256: bec53e033e26188475366ffa86d4fb7bdae902588335955884279d61fc029b37
Description: Swiftweasel is a optimized build of the Mozilla Firefox code for Linux. It is built for different microprocessor architectures and incorporates additional instruction sets.

i think we might consider to move the browser depends to recommends instead.

I dont see any reason why mplayer(standalone app) should depend on xulrunner nor browsers since it doesnt need them i think we should downgrade all browser deps and xulrunner depsto recommends

On Wed, May 14, 2008 at 5:12 PM, John Vivirito <email address hidden> wrote:
> I dont see any reason why mplayer(standalone app) should depend on
> xulrunner nor browsers since it doesnt need them i think we should
> downgrade all browser deps and xulrunner depsto recommends

mplayer doesn't depend on any browser, or browser-related library.

As for the mozilla-mplayer, we could either move browser-related
Depends to Recommends, or include all browser in one OR Depends. The
latter might be a bit wrong in one extreme case:
 - new browser package, named browser-package, gets into Ubuntu archives
 - user wants to use only browser-package, which is compatible with
mozilla-mplayer
 - unfortunately, browser-package still isn't added to that OR browser
Depends, so user is forced to install some other browser, too

It is a very rare situation, but it can happen :).

--
Best regards,
Saša Bodiroža

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Saša Bodiroža wrote:
| On Wed, May 14, 2008 at 5:12 PM, John Vivirito <email address hidden>
wrote:
|> I dont see any reason why mplayer(standalone app) should depend on
|> xulrunner nor browsers since it doesnt need them i think we should
|> downgrade all browser deps and xulrunner depsto recommends
|
| mplayer doesn't depend on any browser, or browser-related library.
|
| As for the mozilla-mplayer, we could either move browser-related
| Depends to Recommends, or include all browser in one OR Depends. The
| latter might be a bit wrong in one extreme case:
| - new browser package, named browser-package, gets into Ubuntu archives
| - user wants to use only browser-package, which is compatible with
| mozilla-mplayer
| - unfortunately, browser-package still isn't added to that OR browser
| Depends, so user is forced to install some other browser, too
|
| It is a very rare situation, but it can happen :).
|
The more i think about this the more i am against adding browsers to the
deps, only because if they are using non-gecko browser they will have to
install one.(yes i know thats the point as mozilla-mplyer wont work on
konq, ect...) since most people using Ubuntu or Xubuntu has a gecko
browser installed already this sould not be a dep. Please move them to
recommends as this will cause too much cruft to be installed if they are
using a minimal system without Ubuntu-desktop but with Gnome-* package.

When you say brower-package you mean a empty package that depends on a
browser? (empty == meta package) just sued to get deps.

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILKDcqig4QTwcPCoRAgqWAJoDnD2S2gUH3QMF6K95sud1LHnwaQCdEzKQ
JaT2o9K5tmGWiMg0e62EVF8=
=nZLq
-----END PGP SIGNATURE-----

On Thu, May 15, 2008 at 10:45 PM, John Vivirito <email address hidden> wrote:
> The more i think about this the more i am against adding browsers to the
> deps, only because if they are using non-gecko browser they will have to
> install one.(yes i know thats the point as mozilla-mplyer wont work on
> konq, ect...) since most people using Ubuntu or Xubuntu has a gecko
> browser installed already this sould not be a dep. Please move them to
> recommends as this will cause too much cruft to be installed if they are
> using a minimal system without Ubuntu-desktop but with Gnome-* package.

I think it's reasonable to add all supported browsers as
mozilla-mplayer dependency. If the user doesn't have supported browser
installed, what's the point of mozilla-mplayer on his system?

> When you say brower-package you mean a empty package that depends on a
> browser? (empty == meta package) just sued to get deps.

I'm thinking on any browser that can make use of mozilla-mplayer. But,
as I said before, that situation is very rare. There are not that many
browsers out there, which would be added, so the previous example is
not that important.

--
Best regards,
Saša Bodiroža

Hi Saša,

On Thu, May 15, 2008 at 09:14:58PM -0000, Saša Bodiroža wrote:
> I'm thinking on any browser that can make use of mozilla-mplayer. But,
> as I said before, that situation is very rare. There are not that many
> browsers out there, which would be added, so the previous example is
> not that important.

You keep saying this, but it's already happened *twice*. Once with xulrunner,
and again now. Why can't we just make it "Recommends" so we don't have to
revisit it again?

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

On Thu, May 15, 2008 at 11:24 PM, Forest Bond
<email address hidden> wrote:
> You keep saying this, but it's already happened *twice*. Once with xulrunner,
> and again now. Why can't we just make it "Recommends" so we don't have to
> revisit it again?

That brings another problem. If the user decides to remove all
browsers that support mozilla-mplayer from his system, the
mozilla-mplayer package will stay installed, while it should be
removed.

--
Best regards,
Saša Bodiroža

May I add that you guys don't forget konqueror-kde4 in the depends?

Swiftweasel comes in several flavors (e.g. swiftweasel-prescott), but I think we could persuade the author to supply a provides.
And don't forget swiftfox - which comes in several flavours and provides www-browser.

Package: swiftfox-prescott
 Version: 3.0pre-2
 Section: web
 Priority: optional
 Architecture: all
 Depends: libc6, libcairo2, libglib2.0-0 (>= 2.8.0), libgtk2.0-0 (>= 2.8.1), libpango1.0-0 (>= 1.10.0), libpng12-0 (>= 1.2.8rel), libx11-6, libxft2 (>> 2.1.1), libxinerama1, libxp6, libxt6, zlib1g (>= 1:1.2.1)
 Replaces: swiftfox
 Provides: www-browser
 Installed-size: 23757
 Maintainer: Jason Halme <email address hidden>
 Description: lightweight web browser based on Mozilla
  Swiftfox is a redesign of the Mozilla browser component, similar to
  Galeon, K-Meleon and Camino, but written using the XUL user interface
  language and designed to be lightweight and cross-platform.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jojo4u wrote:
| Swiftweasel comes in several flavors (e.g. swiftweasel-prescott), but
I think we could persuade the author to supply a provides.
| And don't forget swiftfox - which comes in several flavours and
provides www-browser.
|
| Package: swiftfox-prescott
| Version: 3.0pre-2
| Section: web
| Priority: optional
| Architecture: all
| Depends: libc6, libcairo2, libglib2.0-0 (>= 2.8.0), libgtk2.0-0 (>=
2.8.1), libpango1.0-0 (>= 1.10.0), libpng12-0 (>= 1.2.8rel), libx11-6,
libxft2 (>> 2.1.1), libxinerama1, libxp6, libxt6, zlib1g (>= 1:1.2.1)
| Replaces: swiftfox
| Provides: www-browser
| Installed-size: 23757
| Maintainer: Jason Halme <email address hidden>
| Description: lightweight web browser based on Mozilla
| Swiftfox is a redesign of the Mozilla browser component, similar to
| Galeon, K-Meleon and Camino, but written using the XUL user interface
| language and designed to be lightweight and cross-platform.
|
Im more concerned about deps that we already maintain. I dont see
XULrunner as a dep on that list. What version of XUl will swiftfox handle?

Why would we add konq to deps? konq isnt a gecko browser so it wont run
on it anyway.

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILbLNqig4QTwcPCoRAiJKAJ9ZW3LGIkBYIE8SN1P8a1Ag2eCoVwCeIAEl
OZi1gnZf/HPkIbmCxzus8ao=
=PdAj
-----END PGP SIGNATURE-----

mplayerplug-in (3.50-1ubuntu2) hardy; urgency=low

  * Added support for Firefox 3 xulrunner plugin architecture by linking
    plugins to /usr/lib/xulrunner-addons/plugins. (LP: #193812)
    - updated debian/mozilla-mplayer.links

 -- Jared Greenwald <email address hidden> Mon, 17 Mar 2008 09:49:19 -0400