https://bugzilla.rpmfusion.org/show_bug.cgi?id=5122
--- Comment #7 from Andrew Bauer <[email protected]> ---
(In reply to Nicolas Chauvet from comment #4)
> You can drop Group: Applications/Multimedia
> Also please use ExclusiveArch: %{arm} (I'm still not sure about to move the
> whole rpi target to default to armv7hnl anyway)
Done.
>
> Why a desktop sub-package ?
> Why the desktop file uses enforces "lxterminal" ? Is that really needed ?
> omxplayer been a video player application, running on a desktop seems a
> given. So I would expect to merge the -desktop file into the main package.
omxplayer plays video, but unlike other video players, it does not need a
desktop. It is technically not a desktop application. Omxplayer will render
video right to the monitor on a minimal install of Fedora/Fedberry. That is why
I suspect the desktop file calls lxterminal.
I agree that a desktop subpackage seems a bit unnecessary since it contains
just a .desktop file. That was part of the specfile I started working with. Let
me do some digging to see if I can find a little more background.
(In reply to Xavier Bachelot from comment #6)
> - Shouldn't the version number be 0 and the release
> 3.%{commit_date}git%{commit_short}%{dist} ? I guess upstream is not
> currently using a version number, but in case it happens someday, it'll be
> straight forward to use rather than to need to Epoch the package to override
> the date as the version number.
See long answer below.
> - Add a comment for Patch1 and Patch2, explaining where they come from.
Done.
> - Use a wildcard rather than specify the compression for the manpage
> (%{_mandir}/man1/%{name}.1.*)
Done.
LONG ANSWER:
You are absolutely right that packaging rules dictate a project without a
release should get a version of "0". This issue is similar to the package
review to raspberrypi-vc libs [1]. However, there already exists the same
package in the FedBerry repos, and if we start with release "0" then it can get
overwritten by Fedberry package. There certainly could be a problem, however,
in the future if upstream starts to create releases. As a newer packager, it is
difficult for me to see which path truly has the least risk. For now, I'll
stick with what was approved in the raspberrypi-vc review. Rebuttals as
welcome.
[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=5074#c4
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug._______________________________________________
rpmfusion-developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
