package, package2, package3 naming-with-version exploit

Petr Pisar ppisar at redhat.com
Fri Mar 29 14:01:29 UTC 2013


On 2013-03-29, Tomas Mraz <tmraz at redhat.com> wrote:
>
> I can imagine only one reason for this desire - so that the user can do
> just "yum install foo" when he just wants the latest version of "foo".
>
Basically yes. It's call for semantically separeted API identifier. Now
you have NEVRA string:

What's Name good for? To match upstream name. Putting suffixes to
achieve multiversion as done now is confusing and cannot be handled by
machines.

What's Version good for? To match upstream version.
What's Release good for? To allow packagers to update the same version.
What's Epoch good for? To work around if upstream screws version up.

Pure theorethically we could melt EVR into one unstructured number. But
we don't do that because it would be confusing.

What's Architecture good for? To allow multilib. To install more
instances of the same version. And yum ignores Architecture on purpose. But
don't tell anybody that. Otherwise he could not claim we do not
implement parallel installation.

Where we have API? Nowhere because Fedora assumes only one version of
a package. API should work like Architecture in sense of parallel
instalability, but it shouls provide name spacing for EVR string. API
itself should define orderding to allow selecting latest package across
all builds as already commmentd:

> I can imagine only one reason for this desire - so that the user can do
> just "yum install foo" when he just wants the latest version of "foo".

> What I can see as a possible solution is the following (whether the
> desire above is really worth implementing it is another question):
> Add a new field to the current NEVR fields called for example Branch.
>
Yes the Branch is what I called API above. It's what Gentoo portage
calls slot.

It allows picking highest or best fitting package. It allows breaking
library API without breaking run-time. It allows seemless introduction and
retirement of APIs.

-- Petr



More information about the devel mailing list