<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 29, 2013 at 3:01 PM, Petr Pisar <span dir="ltr"><<a href="mailto:ppisar@redhat.com" target="_blank">ppisar@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 2013-03-29, Tomas Mraz <<a href="mailto:tmraz@redhat.com">tmraz@redhat.com</a>> wrote:<br>
Basically yes. It's call for semantically separeted API identifier. Now<br></div>
you have NEVRA string:<br>
<br>
Where we have API? Nowhere because Fedora assumes only one version of<br>
a package. API should work like Architecture in sense of parallel<br>
instalability, but it shouls provide name spacing for EVR string. API<br>
itself should define orderding to allow selecting latest package across<br>
all builds as already commmentd:<br></blockquote></div><br></div><div class="gmail_extra">Isn't one of the principal problems that lead to calls for transparent multiple version support exactly the _impossibility_ of having an API identifier?<br>
<br></div><div class="gmail_extra">(To explain myself more, I view "API identifier" not as a mere Provides: - that can of course be done and that works already. I'm thinking about an "API identifier" as a mechanism that governs update behavior - i.e. (yum update) tries to replace each package with a newer version that has the same API identifier.)<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In the C world, it's reasonably straightforward: The API identifier is the soname, upstreams that break ABI without bumping the soname are taught not to do that, and rpm handles the soname (and the ELF symbol versions) transparently and straightforwardly. Package names (and hence good suport for multi-versioning) are _completely irrelevant_ for dependency resolution. So far, this seems pretty close to the ideal situation. (The non-ideal part is that the API identifiers need to be manually managed as a component of the package name, but let's ignore that for now.)<br>
<br><br>However, other languages don't have an API identifier. Collecting a few Gem requirements from my system:<br>> s.add_dependency(%q<activesupport>, [">= 0"])<br>> s.add_dependency(%q<activesupport>, ["~> 3.0"])<br>
> s.add_dependency(%q<activesupport>, ["~> 3.0.0"])<br>> s.add_dependency(%q<activesupport>, ["= 3.2.8"])<br></div><div class="gmail_extra"><br>What API identifier would you actually use for rubygem-activesupport? What API identifer would you want to _autogenerate_ for rubygem-activesupport? You'll need "API 3.2.8" at which point upgrades start looking as a little meaningless concept.<br>
<br></div><div class="gmail_extra">Similarly, maven version ranges also don't lend themselves to the concept of "API identifier":<br>> <version>[3.8,4.0)</version><br></div><div class="gmail_extra">
I can construct arbitrary overlapping ranges, so a single API identifier won't work.<br></div><div class="gmail_extra"></div><div class="gmail_extra"> Mirek<br></div></div>