Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=864187 --- Comment #13 from Mario Blättermann <mario.blaettermann@xxxxxxxxx> --- (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_usage > 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review