----- Original Message ----- > From: "Florian Weimer" <fweimer@xxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
