Bug 58933 - Where is the arts entry in bugzilla ???? (arts BUG)
Where is the arts entry in bugzilla ???? (arts BUG)
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: SDL (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-28 03:45 EST by Mario Mikocevic
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-28 03:45:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mario Mikocevic 2002-01-28 03:45:24 EST
Description of Problem:
Since there is NO arts entry in rawhide bugzilla I'm reporting this
as SDL bug :

# rpm -Uvh arts-3.0.0-0.cvs20020127.1.i386.rpm
Preparing...                ########################################### [100%]
package arts-3.0.0-1.cvs20020109.2 (which is newer than
arts-3.0.0-0.cvs20020127.1) is already installed

Well, this is obvious (l)user error in .spec file.
Maybe rpm should know/consider cvs/CVS/date as release numbers.
(yeah I know, AI is hard to achieve :)


Version-Release number of selected component (if applicable):


How Reproducible:
Always.

Steps to Reproduce:
1. rpm -Uvh arts*
2. 
3. 

Actual Results:
No upgrade done.

Expected Results:
Upgrade done.

Additional Information:
Comment 1 Bernhard Rosenkraenzer 2002-01-28 08:23:55 EST
rpm -qi arts shows you arts is part of kdelibs --> that's where the bug report
should go.

The problem is that a stupid mass rebuild script accidentally increased the
version number from 0.cvs20020109.1 to 1.cvs20020109.1 rather than the correct
0.cvs20020109.2; this package was obviously bogus and should never have been
released.

I'm not going to increase the release number of newer builds to 1.* because that
would break things (3.0.0-1 is better than 3.0.0-cvs20020129, so the release
number for CVS code must be smaller than 1), and there's no way to fix the
inadvertant release of a 3.0.0-1.cvs* package.

Rawhide is expected to break, so using rpm --force or rpm --oldpackage is the
correct solution.

Note You need to log in before you can comment on or make changes to this bug.