Adam Spiers (aspiers@suse.com) wrote:
Stephan Kulow (coolo@suse.de) wrote:
On 06.11.2012 12:54, Adam Spiers wrote:
However, in the few ugly cases where multi-version is required, it should be possible to accommodate - rubygemsdeps.rb could generate the following extra Provides:
multiversion(rubygem) multiversion(rubygem-foo) multiversion(rubygem-foo-1) multiversion(rubygem-foo-1_2) multiversion(1.9:rubygem-foo) multiversion(1.9:rubygem-foo-1) multiversion(1.9:rubygem-foo-1_2)
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/ e.g.
multiversion = provides:multiversion(1.9:rubygem-foo)'
which would allow multiple versions of the foo gem to co-exist simultaneously for a 1.9 ruby install.
So I have *still* not heard a convincing reason why we would ever need suffices in the Name: field.
OK, let me give you one: to avoid all the mess you just listed.
It's not any more messy than the automatic Provides: which rubygemsdeps.rb already generates, and has a number of advantages over -1_0 suffixing:
- automatically generated so no manual renaming required by packager
- doesn't pollute the Name: field with version info already in the Version: field
- eliminates confusion in the packaging policy about when to use suffixing and when not to use it
- hidden from the user (e.g. 'rpm -q rubygem-foo' always gives the user the answer they intuitively expect)
- allows multiple minor versions to co-exist on the same machine, just like bundler does
- allows *optional* enabling/disabling of multiversion: - for all gems system-wide - per gem - per gem major version - per gem minor version - per Ruby version and gem - per Ruby version and gem major version - per Ruby version and gem minor version
I thought of more disadvantages to our current policy of suffixing for old versions only[1]: - When updating rubygem-foo from 1.2.x to 1.3.x, there is no reliable way to determine whether anything still depends on the old version (e.g. via a ~> 1.2.5 requirement). So it is impossible to know whether it is sufficient to simply upgrade rubygem-foo from 1.2.x to 1.3.x, or whether a new rubygem-foo-1_2 is also required. - Even if you do find something which depends on the old 1.2.x version, the addition of rubygem-foo-1_2 will not avoid breaking any projects which linkpac to rubygem-foo in (say) d:l:r:e rather than building against d:l:r:e via a <path> entry in the meta project config. - You have to decide how long the suffix needs to be (e.g. rubygem-foo-1 vs. rubygem-foo-1_2 vs. rubygem-foo-1_2_5) and that is effectively hardcoding unreliable assumptions about a) the versioning policy of that particular gem (since sadly not all gems adhere to semver.org) and b) the nature of the other packages' dependencies on foo. Unfortunately these last two disadvantages also apply to a scheme which never used suffices in the BS package name, as well as a scheme which *always* includes the suffix in the BS package name :-/ The fundamental problem here is that linkpac was never designed to express dependencies on a particular version of a package, i.e. it cannot express a version dependency like ">= 1.2" or "~> 1.2". One workaround for this particular problem is 'osc setlinkrev' but it's inherently problematic and also requires manual dependency resolution. Using <path> and building directly against d:l:r:e (say) would give automatic dependency resolution, but is not always appropriate. copypac is another option but is again manual. I should make an important distinction in this discussion: the question of when and how to suffix in the BS package name is different from the question of whether to suffix in the Name: field. AFAICS the multiversion scheme quoted above would allow us to drop suffices from the Name: field, but not from the BS package name. [1] http://en.opensuse.org/openSUSE:Packaging_Ruby#Updating_gem_packages_to_a_ne... -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org