Re: perl module version ordering differing from RPM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John <valhalla@computerdatasafe.com.au> writes:

> On Saturday 31 August 2002 23:10, Chip Turner wrote:
> > > Try reporting that as a bug and see what the response is.
> > 
> > But it isn't a bug.  It's just how the algorithm works.
> 
> A badly-chosen algorithm is still a bug.

That's strictly opinion.  The people (including non-Red Hat employees)
that work deeply with RPM daily don't really agree with your opinion.

RPM treats version components as integers, not floating point
numbers.  That's the core of it.  So:

1.2.30.04 is (1, 2, 30, 4)
not
1.2.30.04 is (1, 2, 3, 04)

Then comparison is performed component-wise.  It's simple, easy to
understand, and quick to execute.  What more do you want?  Do you
really want 1.30 being the "same" as 1.3?  The majority of open source
projects version based on tuples of integers; the classic badguy here,
perl, even changed (from 5.00503 to 5.5.3).  In kernel land, if you
run 2.4.2, you're significantly less stable than if you run 2.4.20.
Would you really want rpm to treat them the same?

I think you'll find the chosen algorithm works as one would
intuitively expect the vast majority of the time.  As was stated, if
you have suggestions for improvement, feel free to post them.

Chip

-- 
Chip Turner                   cturner@redhat.com
                              Red Hat, Inc.



_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list

[Index of Archives]     [Kernel Newbies]     [Red Hat General]     [Fedora]     [Red Hat Install]     [Linux Kernel Development]     [Yosemite News]

  Powered by Linux