Description of problem: Currently, if the installonlypkgs is udpated, where the version stays the same while the release is changed, the newly updated library is installed. However, for RubyGems (and there might by other situations), it would be beneficial for cases, where only release is changed, to remove the old version and install the new one, while if the version is changed, then keep the old version and install new one. Note that this should be some additional options, since the behavior of kernel installation should stay the same. Actual results: foo-1.0.0-1.rpm => foo-1.0.0-2.rpm Both packages stay on the system Expected results: foo-1.0.0-1.rpm => foo-1.0.0-2.rpm Only foo-1.0.0-2.rpm packages stays on the system while foo-1.0.0-1.rpm => foo-1.0.1-1.rpm There are both packages available on the system.
Vit, as much as I'd like to go ahead with this the majority of the packaging team is against. One of their main concerns is that there's too much work involved for something that is already possible. Do you know about a scenario where mixing the name and version together [1] won't let you achieve everything you expect from your proposal in comment 0? [1] http://rpm.org/wiki/PackagerDocs/MultipleVersions
Ales, I appreciate your support. There are several reasons why the "name and version" does not work: 1) It prevents updates on the first place. There is not upgrade path from foo_1 package to foo_2, whereas packages with my proposal can be updated as they always were. 2) It leads to unneeded duplication of versions, which leads to confusion. Is it feasible to have package foo_1-2.0.0? Or is that possible to have foo_2-1.0.0? 3) It is not obvious how to version package. I have package foo-3.0.0, then foo-3.1.0 is released? Should I create new package foo-3_1-3.1.0 and keep foo at 3.0.0 version? Or opposite, update foo to foo-3.1.0 and create new package foo_3_0? Or what if come version 4.0, or some minor update 3.1.1? And bit of off-topic, regarding the current Fedora workflow, each "name and version" package would need new review, new git repo, there is harder to maintain changes between different git repositories etc. So although you want temporary less work, you imply much more work for packagers in the future. Note that this is blocking everybody's favorite applications, such as Redmine, Gitourius or Gitlab from being packaged for Fedora. Just as an example, here is list of Gitorious dependencies [1]. Does it mean that somebody who wants to import Gitorious into Fedora needs to duplicate half of dependencies, due to different versions? [1] https://fedoraproject.org/wiki/User:Ktdreyer/Gitorious
(In reply to comment #1) > One of their main concerns is that there's too much work involved for > something that is already possible. BTW there is possible to install RPMs without YUM, but nobody complained that YUM was too much work, just because installing RPM was already possible. Therefore this argument is moot.
(In reply to comment #2) > Ales, I appreciate your support. There are several reasons why the "name and > version" does not work: > > 1) It prevents updates on the first place. There is not upgrade path from > foo_1 package to foo_2, whereas packages with my proposal can be updated as > they always were. This is valid point, thanks. Please check http://rpm.org/wiki/ReleaseBasedVersioning if use cases there cover the functionality you request. Don't mind the technical solution, as it has already been scrapped. We are now trying to come up with something more generic. > 2) It leads to unneeded duplication of versions, which leads to confusion. > Is it feasible to have package foo_1-2.0.0? Or is that possible to have > foo_2-1.0.0? Sure, why not? Technically speaking foo_2 is entirely different package. However I find that much more confusing than just keeping foo_1-1.a.b and foo_2-2.x.y. > 3) It is not obvious how to version package. I have package foo-3.0.0, then > foo-3.1.0 is released? Should I create new package foo-3_1-3.1.0 and keep > foo at 3.0.0 version? Or opposite, update foo to foo-3.1.0 and create new > package foo_3_0? Or what if come version 4.0, or some minor update 3.1.1? That's really up to you. Personally I like the latter approach better. > And bit of off-topic, regarding the current Fedora workflow, each "name and > version" package would need new review, new git repo, there is harder to > maintain changes between different git repositories etc. So although you > want temporary less work, you imply much more work for packagers in the > future. Note that current Fedora workflow won't support this new versioning anyway even if we provide the functionality. > Note that this is blocking everybody's favourite applications, such as > Redmine, Gitourius or Gitlab from being packaged for Fedora. > > Just as an example, here is list of Gitorious dependencies [1]. Does it mean > that somebody who wants to import Gitorious into Fedora needs to duplicate > half of dependencies, due to different versions? The correct approach is to adapt Gitorious to the latest versions available. Every other approach is just laziness of developers which should not be sanctioned by package reviewer. Related to this point: please note that even if we (as in packaging team) provide you the functionality you request, you won't convince FESCO to enable this feature in Fedora main repos hence those applications you are talking about won't make it to Fedora unless they are adapted to latest package versions as I already mentioned.
(In reply to comment #4) > (In reply to comment #2) > > Ales, I appreciate your support. There are several reasons why the "name and > > version" does not work: > > > > 1) It prevents updates on the first place. There is not upgrade path from > > foo_1 package to foo_2, whereas packages with my proposal can be updated as > > they always were. > > This is valid point, thanks. Please check > http://rpm.org/wiki/ReleaseBasedVersioning if use cases there cover the > functionality you request. Don't mind the technical solution, as it has > already been scrapped. We are now trying to come up with something more > generic. Well, I was thinking about more generic solution before I submitted this RFE, however I was afraid, that it would be overcomplicated and we can't see every corner-case while the simpler case I proposed would satisfy my needs. Nevertheless I am definitely not against better solution :) > > 2) It leads to unneeded duplication of versions, which leads to confusion. > > Is it feasible to have package foo_1-2.0.0? Or is that possible to have > > foo_2-1.0.0? > > Sure, why not? Technically speaking foo_2 is entirely different package. > However I find that much more confusing than just keeping foo_1-1.a.b and > foo_2-2.x.y. Simply put, the version is duplicated in name and it tends to be confusing and leads to inconsistencies and errors. Let me take python as an example. There is currently python-2.7.3. Then somebody comes and creates python3-3.0.0. Later, the python maintainer decides that it is time to update the python package and as a result, we'll have pytho-3.0.0 package. So now we have two packages, of the same versions, with different maintainers. Which one would you choose? Is that invalid use-case? For python, it might be extreme, but what about [1]? > > 3) It is not obvious how to version package. I have package foo-3.0.0, then > > foo-3.1.0 is released? Should I create new package foo-3_1-3.1.0 and keep > > foo at 3.0.0 version? Or opposite, update foo to foo-3.1.0 and create new > > package foo_3_0? Or what if come version 4.0, or some minor update 3.1.1? > > That's really up to you. Personally I like the latter approach better. I was trying to point out that it is not obvious what will be next version number nor when it will be released or what will be impact. So you don't have always qualified information not to mention that even though you might maintain foo package, it does not mean that somebody, who is going to maintain foo_x package will consider all consequences > > And bit of off-topic, regarding the current Fedora workflow, each "name and > > version" package would need new review, new git repo, there is harder to > > maintain changes between different git repositories etc. So although you > > want temporary less work, you imply much more work for packagers in the > > future. > > Note that current Fedora workflow won't support this new versioning anyway > even if we provide the functionality. Yes, hence the off-topic :) > > Note that this is blocking everybody's favourite applications, such as > > Redmine, Gitourius or Gitlab from being packaged for Fedora. > > > > Just as an example, here is list of Gitorious dependencies [1]. Does it mean > > that somebody who wants to import Gitorious into Fedora needs to duplicate > > half of dependencies, due to different versions? > > The correct approach is to adapt Gitorious to the latest versions available. > Every other approach is just laziness of developers which should not be > sanctioned by package reviewer. Uh, there are developers of gitorious and there are packagers for Fedora. Although I'd love every upstream to follow upstreams of projects they are using, it is not always the case. Unfortunately even Red Hat developers does not follow this practice, so .... > Related to this point: please note that even if we (as in packaging team) > provide you the functionality you request, you won't convince FESCO to > enable this feature in Fedora main repos hence those applications you are > talking about won't make it to Fedora unless they are adapted to latest > package versions as I already mentioned. Without tools, there is no hope :) [1] http://lists.fedoraproject.org/pipermail/devel/2012-April/165946.html
(In reply to comment #5) > > > 1) It prevents updates on the first place. There is not upgrade path from > > > foo_1 package to foo_2, whereas packages with my proposal can be updated as > > > they always were. > > > > This is valid point, thanks. Please check > > http://rpm.org/wiki/ReleaseBasedVersioning if use cases there cover the > > functionality you request. Don't mind the technical solution, as it has > > already been scrapped. We are now trying to come up with something more > > generic. > > Well, I was thinking about more generic solution before I submitted this > RFE, however I was afraid, that it would be overcomplicated and we can't see > every corner-case while the simpler case I proposed would satisfy my needs. > Nevertheless I am definitely not against better solution :) The question still stands. Does the document cover your use cases or are there any missing? As a reply to all your other points: those are not technical issues, only inconveniences. We need some strong technical points to push this functionality through since it includes a number of components needing extensive modifications: rpm, rpmbuild, repository related tools, yum, hawkey/dnf. I'm on your side here that's why I need to gather arguments why we need to do this.
My take on this: http://rpm.org/wiki/UpgradeRanges
(In reply to comment #6) > The question still stands. Does the document cover your use cases or are > there any missing? I would say that your usecases covers mine, however there is missing context :) So let me explain. All I want to achieve is similar behavior as RubyGems work + some necessary extensions due to RPM features. Let me show the examplehow RubyGems manages the libraries: $ gem list *** LOCAL GEMS *** # gem install foo $ gem list *** LOCAL GEMS *** foo (1.0.0) After some period of time ... # gem update foo $ gem list *** LOCAL GEMS *** foo (1.0.0, 2.5.4) But you actually need the 1.6.4 version, because 2.x has different API, so you can do: # gem install foo -v 1.6.4 $ gem list *** LOCAL GEMS *** foo (1.0.0, 1.6.4, 2.5.4) As you can see, all the versions are kept on the system. But you want to move to the latest version, so now you can do: # gem cleanup foo $ gem list *** LOCAL GEMS *** foo (2.5.4) As you can see, the RubyGems packages are nonconflicting. You can install them side by side and they behave as a installonlypkgs. However, in RPM world, we have not only version, but also release. The releases conflict between each other, but they are contains just bugfixes and security fixes, no API/ABI changes. So it is natural that the releases should replace the original version. That is why I asked for this feature. This is how RubyGems works. This is how Ruby community works. It is perfectly fine to have two different versions of the library on the system. At the end, the difference in Major version could mean that you support different API version. So it does not mean that you have to immediately update as soon as there is new API available. If we want Ruby programmers to use the RPM versions, which definitely has benefits (you don't need compiler on your system to install binary extensions etc), we should allow YUM to behave the same. I am speaking for Ruby, but I guess that for Java, the JARs are nonconflicting as well. So this might help also others, not just Ruby
(In reply to comment #7) > My take on this: http://rpm.org/wiki/UpgradeRanges Unfortunately, you last point (what is the number? 4.1? shouldn't it be just 5?) can break Ruby application. Since RubyGems contains their own metadata about version dependencies. For example, I have bar package which depends on your foo package, and it has internally specified dependency bar ~> 1.4.0. That means use all version >= 1.4.0 but < 1.5.0. And now you forcedly removed the 1.4 version and replaced it with 1.5 and the application breaks. For me as a maintainer of foo library is natural to backport the security fix into 1.4, so foo-1.4-2 is released, application continue to work and is secure. So what is the benefit of upgrading to 1.5? I am not maintainer of bar package, so I cannot fix the dependency there. So although implementing your proposal might be useful in some cases, it does not solve my issue while it brings more questions IMO.
(In reply to comment #9) > (In reply to comment #7) > > My take on this: http://rpm.org/wiki/UpgradeRanges > > Unfortunately, you last point (what is the number? 4.1? shouldn't it be just > 5?) can break Ruby application. Since RubyGems contains their own metadata > about version dependencies. For example, I have bar package which depends on > your foo package, and it has internally specified dependency bar ~> 1.4.0. > That means use all version >= 1.4.0 but < 1.5.0. And now you forcedly > removed the 1.4 version and replaced it with 1.5 and the application breaks. Right. But as I explained to you yesterday: the only acceptable solutions for this problem have to provide enough flexibility for many cases. If this is not right for the ruby world it's OK, just stick to the plain case 4. > So although implementing your proposal might be useful in some cases, it > does not solve my issue while it brings more questions IMO. Hmmm. I am not sure I follow there: does applying the case 4. not give you exactly the desired behavior? (fixed an extra version part there. also note that 4.1 doesn't apply for your case).
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > My take on this: http://rpm.org/wiki/UpgradeRanges > > > > Unfortunately, you last point (what is the number? 4.1? shouldn't it be just > > 5?) can break Ruby application. Since RubyGems contains their own metadata > > about version dependencies. For example, I have bar package which depends on > > your foo package, and it has internally specified dependency bar ~> 1.4.0. > > That means use all version >= 1.4.0 but < 1.5.0. And now you forcedly > > removed the 1.4 version and replaced it with 1.5 and the application breaks. > > Right. But as I explained to you yesterday: the only acceptable solutions > for this problem have to provide enough flexibility for many cases. If this > is not right for the ruby world it's OK, just stick to the plain case 4. > > > So although implementing your proposal might be useful in some cases, it > > does not solve my issue while it brings more questions IMO. > > Hmmm. I am not sure I follow there: does applying the case 4. not give you > exactly the desired behavior? (fixed an extra version part there. also note > that 4.1 doesn't apply for your case). Yes, 4 is what I need. I don't object 4.1 as long as it helps to get me 4 ;)
Making this possible would be a huge step forward for Fedora as a Ruby platform - people are already doing what is described here; they just do it outside of yum/rpm, and instead rely on the Ruby tools gem and bundler. That situation is worse than it would be if yum/rpm would support installation of multiple versions of the same ruby gem: (1) quite a few ruby gems are bindings to native libraries, and installing such gems requires installing the native libs with yum/rpm, then the Ruby gems with gem/bundler (2) rubygems do not go through a controlled build process (in fact, build and install are the same step with gems) (3) rubygems do not have the same signature mechanisms as rpm's Allowing what this ticket asks for would let us show to the Ruby world that there is a lot of value in using Fedora, and in native packaging. Without it, the status quo will just continue, with much bigger drawbacks than the concerns expressed here.
> Allowing what this ticket asks for would let us show to the Ruby world that > there is a lot of value in using Fedora, and in native packaging. Without > it, the status quo will just continue, with much bigger drawbacks than the > concerns expressed here. Please note, that I discussed a possibility of implementing a yum plugin, that would allow parallel installation of multiple versions of packages. It was the idea of yum people to do it as a plugin, so that no current functionality is touched/broken (I agree that it makes sense to let yum itself untouched, at least for start). My proposal for this plugin is at [1]. Unfortunately, yum team doesn't consider this to be a priority, nor a good thing to do, so the proposal was not accepted - I was however told that I'm free to implement the plugin myself :) So thank you for stating your opinion here. I believe that if more people ask for this functionality, yum team will reconsider. [1] https://fedoraproject.org/wiki/User:Bkabrda/YumParallelInstall
You are not entirely correct. We proposed just the alias command set to be done as a plugin. As I already told you, I have serious doubts the extension as you see it will be doable as a plugin. As to our rejection of the functionality: we discussed this on another rpm meeting and the general consensus was that this is too much work for a very little gain - virtually every component in packaging stack would need non-trivial changes to implement something that is already possible, even though it is sort of a hack. Therefore a *serious* justification for this is necessary to raise its priority at least a little bit. I mean no disrespect but I'm sure you understand that desire to attract some Ruby developers to Fedora isn't serious enough to change something as big as this, considering that it was acceptable for everyone interested for the last 15 years. But back to the technical perspective: the general opinion is that the change as you request it will not be implementable simply as yum plugin. As I already outlined, it will most likely require changes in yum core. Also if we want to support something like this, a whole lot of code has to be adjusted through yum, dnf and rpm to ensure that all components are on the same page.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Should this bug be marked as an RFE to avoid autoclosing?
We are not going to "fix" this. Installonly pkgs should stay installed whatever the release is. It could be done by plugin through.