[Bug 1388945] Review Request: gnome-shell-extension-media-player-indicator - Control MPRIS2 capable media players : Rhythmbox, Banshee, Clementine and more

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1388945



--- Comment #10 from Andrew Toskin <andrew@xxxxxxx> ---
I just noticed that the spec says it requires GNOME 3.20+, but the extension's
metadata.json file says it supports 3.16. This maybe isn't a big deal for
Fedora, since Fedora 23 reached end-of-life. But allowing GNOME 3.16 would make
your package usable in EPEL... if/when they rebase to a version of GNOME newer
than 3.14.

In any case, I think it would be better to stick with the upstream's stated
supported versions of GNOME, unless you *know* the extension does not actually
work with GNOME older than 3.20.


(In reply to mgansser@xxxxxxxx from comment #9)
> i activated it with  gnome-shell-extension-prefs

Turns out my problem with Banshee was that I needed to enable the MPRIS D-Bus
Interface extension in the Banshee preferences.
https://github.com/eonpatapon/gnome-shell-extensions-mediaplayer/issues/270

I feel like this is going to be a common point of confusion for new users, but
I'm not sure how we could avoid it. It's already noted in the packaged README,
but how many people read those? Not me, apparently :P

FYI: The method used to activate the extension shouldn't really matter.
Launching gnome-shell-extension-prefs, the GNOME Tweak Tool, or running the
gnome-shell-extension-tool command line -- it's all the same.

Also, the extension does show up in Tweak Tool now. I had reloaded GNOME Shell
(Alt+F2, r, Enter), but maybe it still needed me to logout and login for some
reason.


> I think it is a PreRelease ?

I guess that depends on whether upstream ever plans to tag releases, and what
they intend their first version number to be. Some projects use 0.1 or 1.0 for
their first official release. If they tag their first release as version 0.1,
then you're okay: You would simply bump your Release tag from a "prerelease"
number (0.x) to a regular release (1). And if they tag version 1.0, then that
will always be sorted as newer than version 0.1, so you'd still be good.

However, some developers really like to count from 0, and tag their first
release as 0.0 -- and *that* would be a problem for your package, because RPM
won't recognize the tagged version 0.0 as being newer than the version "0.1"
you've been packaging. You would have to add an Obsoletes tag or something, and
things would get messy...

So if upstream doesn't plan on ever tagging their releases, or if they are
undecided on their versioning scheme in any way, I would set the spec's Version
to plain 0. And continue with the "prerelease" Release tag you're using, unless
or until upstream formally designates an actual version.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]