Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=864187
--- Comment #13 from Mario Blättermann <mario.blaetterm...@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_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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review
