Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=864187
--- Comment #13 from Mario Blättermann <mario.blaettermann(a)gmail.com> ---
(In reply to comment #12)
(In reply to comment #11)
> Requires: %{name}
> is insufficient here. You'll need a fully versioned dependency:
> Requires: %{name}%{?_isa} = %{version}-%{release}
Well, I know I should do this, but the think here is MCAD doesn't really
need the exact same version and release as OpenSCAD. In my case, you should
be able to update openSCAD or MCAD separately. I mean, you can simply run
OpenSCAD 2012.11.01 and MCAD form 2012.05.10, it works.
Well, could be, but with full versioning you make sure that both packages will
be upfdated, which avoids updating only one by accidence. Of course I believe
that it works for the time being, but this could change in the future.
> Your package contains a *.desktop file, which needs to be
installed
> separately or validated:
>
http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_u...
Will do that.
> Some warnings from rpmlint:
>
> openscad.src:12: W: macro-in-comment %{name}
> There is a unescaped macro after a shell style comment in the specfile.
> Macros
> are expanded everywhere, so check if it can cause a problem in this case and
> escape the macro with another leading % if appropriate.
The macros are there uncommented, so they can be evaluated if someone wants
to recreate the source tarball.
The macros are "commented" by the hash line. It is not needed, drop it.
> The package versioning could cause some problems when upgrading
it once a
> fully versioned tarball has been released. Please read the following:
>
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
I will certainly read that, just for the record, the date based versioning
is not something I've invented, if you build OpenSCAD, the version used is
todays date. I overwrite that with:
qmake-qt4 VERSION=%{version} PREFIX=%{_prefix}
Othervise the version (in program's About and such) would depend on the date
of building.
What would you suggest? This?
Version: 2011.12 (Latest stable)
Release: 1.20121031gitb04734cbf5%{?dist}
That would mean in program itself, the version would be noted as 2011.06 (a
bit old).
What about:
Version: 2012.10 (used version, without day)
Release: 0.31.1{?dist} (0 at the beginning, 31 as the day and .1 so I can
bump it)
That would mean in program itself, the version would be noted as 2012.10
(seems OK).
If there is a tarball (e.g. 2012.10) released, I'll do:
Version: 2012.10
Release: 1{?dist}
This should work, right?
This should work, but prepend a version number "0-" as proposed in the
guidelines to make sure that a future version "0.1" (or anything similar) gets
the correct upgrade path. Or must we not expect such a versioning?
--
You are receiving this mail because:
You are on the CC list for the bug.