https://bugzilla.rpmfusion.org/show_bug.cgi?id=2405
Karel Volný <kvolny(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://ultrastardx.sourcefo
| |rge.net/
--- Comment #4 from Karel Volný <kvolny(a)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.