----- Original Message -----
From: "Florian Weimer" <fweimer(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Friday, June 21, 2013 3:00:36 PM
Subject: Re: A need for build triggers & automatic rebuilds
On 06/21/2013 08:28 AM, Krzysztof Daniel wrote:
> OSGI records that there is a file
> org.eclipse.jetty.http_9.0.3.v20130506.jar that holds a plugin with
> version 9.0.3.v20130506. That version goes at the build time in a couple
> of places (including metabundle).
Such exact dependencies are fundamentally broken and do not scale. We
cannot rebuild the whole world just for minor (say, security) updates.
Lying about the version number (so that the new version looks like the
old one to OSGi) doesn't strike me as a good idea, either, because it
will confuse developers and other tools.
I tried to bring this up on the Project Jigsaw mailing list a couple of
years ago, but I'm not sure if I brought across this point. From my
point of view, these Java module frameworks refuse to acknowledge that
there is extensive experience with distro-level release engineering.
(Basically, exact dependencies and multiple versions of the same code
might be convenient now, but will seriously hurt you down the road.)
> Exact match can't be used at all, because if jetty is updated, then it
> will be impossible to install Eclipse.
Well, if it doesn't work with the old version, that's the right thing to do.
I believe Debian relaxes the OSGi-generated dependencies on system
libraries. Fedora should do the same thing in its Eclipse packaging.
Just to clarify a bit - this is not a limitation of OSGi. It's the Eclipse
implementation being faulty of this. And when I say Eclipse implementation I mean Eclipse
platform because the actual OSGi runtime in Eclipse (called Equinox) works perfectly with
version ranges and doesn't suffer from this problem at all. It's the Eclipse IDE
that suffers from this due to legacy reasons.
This shows another problem though: expressing version range in a spec file e.g there is no
easy way to say I want a package that provides osgi(smth) [1.0.0, 1.5.0). If you try to
express it with RPM requires as two statements:
Requires: osgi(smth) >= 1.0.0
Requires: osgi(smth) < 1.5.0
it's not exactly the same as having packages providing osgi(0.9) and osgi(1.6.0) will
satisfy this requirements too. I know this is hypothetical but it shows the inability to
require version range in RPM terms reliably. And the way to get that but not fail-proof is
too verbose now.
Alexander Kurtakov
Red Hat Eclipse team
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel