DNF is completly unable to act with local packages

[Stanislav Ochotnicky]

On Sat 07 Nov 2015 10:18:14 AM EST Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> 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)

Above relies on rpm to sort b before r. It also assumes as others have
mentioned that you don't have an emergency situation where you need to
do one-off in the middle.

> 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.

By "version" you are talking the upstream beta/rc etc labels right?
Because you certainly can and should reset the release number on 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.

Meh, you are not the first nor the last. It's just that we (rightfully?)
hold package managers to higher standards

--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Business System Analyst, PnT DevOps PMO Team - Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com