[Bug 2405] Review Request: ultrastardx - A free OpenSource karaoke game

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2405

Karel Volný <kvolny at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://ultrastardx.sourcefo
                   |                            |rge.net/

--- Comment #4 from Karel Volný <kvolny at redhat.com> 2012-08-15 11:34:06 CEST ---
(In reply to comment #2)
> * I will look into the data files. I didn't add them because they're a
> different source.

hm, thinking about it a bit, maybe they'd fit rather in a separate package than
in a subpackage, as the data are not likely to change that often

> * The reason for the svn checkout is because the released version requires too
> much changes to be compatible with recent ffmpeg versions: the API for ffmpeg
> seems to have changed drastically, which is reflected in the SVN revision.

okay, let's go with a svn snapshot then

> * The page you linked to also says "and optionally, up to 13 characters (ASCII)
> alphanumeric characters that could be useful in finding the revision in the
> revision control system.", so it is an option according to the Fedora naming
> guidelines, and I like this system because it's clear at once which version I
> used for the creation of the SRPM.

(In reply to comment #3)
> I do, however, agree that I would need to edit the version to match the
> guidelines correctly, by putting the svn checkout date and revision id in
> Release, and putting Version 1 (for example).

I said "Release like ...", not that you have to use this exact string :-)

it's perfectly okay to put in the svn revision number as long as the whole NVR
can be sorted chronologically (yes, we have the "Epoch" for special cases, but
it is better to avoid it as it is not directly visible to the user)

so, the latest stable version is 1.1 and we can expect the next to be possibly
1.1.1 or 1.2 ... but it is not released yet, and as the code we're going to use
is newer than 1.1 but it will be older then the future 1.x(.y), the
version-release has to fit somewhere in between


(In reply to comment #2)
> * debuginfo will only be handled automatically if they are extracted during RPM
> generation (as far as I know), which is not the case: ultrastardx generates
> them (always in /usr/lib, as specified in the SPEC) "manually" while building,
> thus circumventing the RPM debuginfo extraction.

well, it may be worthy to take a look if this could be disabled, leaving the
work upon rpm

if not, then at least the files should be put into -debuginfo subpackage
manually, as debug files should not be installed by default

> * The building is indeed broken since a version of ffmpeg that was released
> sometime after my review request was posted. I will try to see if a recent
> checkout fixes the problem, and else request a new release from upstream.

ok; maybe an explicit version dependency should be added then

-- 
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.