Versions

Gábor Paller gaborpaller at gmail.com
Sun Nov 1 09:20:22 UTC 2015


" I'd suggest
something more monolithic, with all the protocol versions in a single
snap,"

I don't need such a complicated setup, I develop research prototypes (and
spend too much time with the intricacies of the Snappy packaging sytem).

All I say that OSGi went through this, Say, you have framework1.0 and you
build app1.0 that depends on framework1.0. Later on, you introduce
framework2.0 and you build another app, anotherapp1.0 that depends on
framework2.0. Now it just so happens that you need to install app1.0 and
anotherapp1.0 on the same system. This means that you have to also install
framework1.0 and framework2.0 at the same time and you have to be able to
tell that app1.0 uses framework1.0 and anotherapp1.0 uses framework2.0.

Different solutions may exist for this problem (in OSGi, you define a
filter including all sorts of metadata, including the version and the
package manager automagically gives you a handle to the correct version)
but the previous solution when the package path contained the version
number was simple and solid.

Regards,
Gabor

On Sat, Oct 31, 2015 at 1:23 AM, John Lenton <john.lenton at canonical.com>
wrote:

> On 30 October 2015 at 19:36, Gábor Paller <gaborpaller at gmail.com> wrote:
> > Having more than one version installed and invoking a specific version.
> > Basic requirement in OSGi.
>
> they might be installed, but they won't be active -- which means
> you're calling them directly, unconfined? Or maybe I'm
> misunderstanding something.
>
> If I understand correctly you're using the package version to
> distinguish protocol versions (is that what osgi calls them?), but
> that feels wrong, especially given that you need to have several
> different ones installed (and active) at the same time. I'd suggest
> something more monolithic, with all the protocol versions in a single
> snap, or if you want multiple snaps, making the name include the
> protocol version, if that makes sense; keep in mind that in multiple
> snaps you'd typically struggle to share libraries for example.
>
> HTH,
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151101/f918eb04/attachment.html>


More information about the snappy-devel mailing list