Adam Spiers (aspiers(a)suse.com) wrote:
Stephan Kulow (coolo(a)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:
and then any product-oriented rpm could install the appropriate
multiversion policy / policies into /etc/zypp/multiversion.d/
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
- 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:
- 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
- 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".
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.
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org