DNF is completly unable to act with local packages

[Panu Matilainen]

On 11/18/2015 04:15 PM, Stanislav Ochotnicky wrote:
> 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.

And? These things also rely on rpm to sort 1 before 2. Not to mention a 
whole pile of other, far more obscure rules than those.

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

Beta/rc are part of the version just as much as micro-versions are. That 
they are traditionally mapped to the tail end of the release in rpm 
world is just another historical rpm abomination.

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

Right. Only took eight years for anybody to notice ;)

	- Panu -