DNF is completly unable to act with local packages

[Panu Matilainen]

On 11/07/2015 04:41 PM, Michael Schwendt wrote:
> On Sat, 7 Nov 2015 13:20:03 +0100, Reindl Harald wrote:
>
>> Error: nothing provides rpm-libs(x86-64) = 4.13.0-0.rc1.5.fc23 needed
>
> 0.rc1.5.fc23 ???
>
> *sigh*  My motivation to do package reviews is hurt a lot by bad examples
> like that. It's as if some people put a lot of effort into trying to ignore
> the packaging guidelines:
>
>    https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
>
>   => 0.5.fc1.fc23  is what it's supposed to be
>
> Why apply the pre-release versioning scheme, if another scheme works, too?
> This time even in the RPM package itself. Explain that to new packagers!
> All you can do is tell them that there are packaging guidelines and
> pitfalls, and that some people hate the guidelines.

Hmm, I've been "guilty" of doing this in the past, whether the current 
version is just using precedent from the changelog or knowingly picked I 
dont know.

Frankly I didn't even realize the 0.rc1.X scheme was against the 
guidelines since to me this is the (obviously) correct way to do it with 
predictable pre-release names (its predictable when you're the one doing 
the upstream tarballs), where the versioning goes like this:

0.beta1.1
0.beta1.2
0.beta1.3
0.beta2.1
0.beta2.2
0.rc1.1
0.rc1.2
[...]
0.rc1.5
0.rc2.1
1 (for the final)

The scheme in guidelines of course works no matter what wacko 
names-of-pet-ponies versions upstream tarballs may have, but to me its 
"wrong" in the sense the release number doesn't get reset between 
version changes. Not that I'm defending going against the guidelines or 
arguing for changing it (I'm way too old to get involved in THAT again), 
just explaining where this particular offense in case of rpm probably 
originates from. Feel free to consider it as an apology for setting a 
bad example.

	- Panu -