Le mer. 15 juil. 2020 à 12:10, Antonio T. sagitter
<[email protected]> a écrit :
>
> On 15/07/20 11:36, Nicolas Chauvet wrote:
> > Le mar. 14 juil. 2020 à 22:53, Antonio T. sagitter
> > <[email protected]> a écrit :
> >>
> >> Hi all.
> >>
> >> As you probably already know, PPSSPP is now provided into separated
> >> rpms, in this way:
> >>
> >> - ppsspp-sdl, this is PPSSPP with SDL frontend
> >> - ppsspp-qt, this is PPSSPP with Qt frontend
> >> - ppsspp-data and ppsspp-libs respectively for data files and libraries
> >>
> >> `ppsspp-qt` has also an own desktop icon for running correctly the
> >> interface on Wayland.
> >>
> >> This mail is for asking to those that uses PPSSPP to try this new
> >> release and check if the sound of any games is fully played without
> >> distortions, since i seen this issue in my tests.
> >>
> >> If someone observes sound problem, please open a bugzilla ticket
> >> including details.
> >
> > Hello Antonio,
>
> Hi.
>
> >
> > Can you confirm the following ?
> > - What is the behaviour if using dnf install ppsspp ?
> > - Is there any appdata file provided in any flavor ? (can you provide
> > one if missing)
>
> ppsspp (that was only Qt version of PPSSPP in the old packaging
> releases, broken in Wayland) is obsoleted by installing `ppsspp-sdl` or
> `ppsspp-qt` or both.
Can you please have add a virtual provide ppsspp for the qt version so
the old package get transitioned to the qt version automatically (also
dnf install ppsspp will work).
(or look at the other proposal).
> > - Is it possible to install both sdl and qt at the same time ?
>
> Yes.
>
> > - Can you make changes so that ppsspp-sdl is installed if SDL(2)
> > package is available.
> > - Same for qt (-> so that end-users don't have to figure out which
> > sub-package is relevant of their system)
>
> I don't understand this point: `ppsspp-sdl` already requires libSDL2
> when install.
Yep This is a long standing issue most package maintainers behave
badly when it comes to sub-packages IMNSHO.
Basically you are breaking an "interface with end-users" when dnf
install ppsspp doesn't work anymore. Whereas it can be easily
workarounded by searching which package to install. It's also very
irritating to remember how one package maintainer broke software into
small pieces and which design pattern was "more or less arbitrarily
chosen".
I've already raised this point for the kodi case some time ago in this
mailing list. (you can have a look at kodi packaging for the
implementation detail).
But basically if you merge back the -data sub-package as the main
(that can still be noarch), and add:
Requires: (%{name}-qt or %{name}-sdl)
Suggests: (%{name}-qt if qt5-qtbase)
Suggests: (%{name}-sdl if SDL2)
This should behave as appropriate for less sub-packages "scumbling..."
So this is only two solutions out of many, but the main point is to
keep everything works as appropriate with dnf install ppsspp
> > Finally can you document that packaging change into upstream website
> > (once corrected if relevant).
> >
>
> ??
> Should i communicate to upstream what we do with our RPMs?
> I guess upstream is not very interested about.
What makes you think so ? At least using this page leaves room for
having our package installation documented.
https://build.ppsspp.org/?page/downloads#linux
For the same reason that I have it documented in the vlc case upstream:
https://www.videolan.org/vlc/download-fedora.html
Of course, having an appdata file helps to have the package
advertised, but I expect many end-users still search for upstream
pointers over dnf or "softwares".
I hope this helps.
_______________________________________________
rpmfusion-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
