DNF is completly unable to act with local packages
pmatilai at laiskiainen.org
Sat Nov 7 15:18:14 UTC 2015
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:
> => 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
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:
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
- Panu -
More information about the devel