Skip to content

Alternatives.json destination requires common value between versions #18

@ppslim

Description

@ppslim

https://github.com/cloudera/cm_ext/wiki/The%20alternatives.json%20file

The alternatives.json page describes the natural behaviour of the update-alternatives command is the destination is already occupied. However it does not talk about a situation in which it is currently occupied by an existing alternative by the same name, but the destination differs.

An example is the famous API differences in Guava between 11 and 16.

A Parcel may be employed to upgrade an application in which the Guava dependency changes. Thus naturally, the alternatives may change from.

    "guava" : {
      "destination": "/opt/application/lib/guava-11.0.2.jar",
      "source": "lib/guava-11.0.2.jar",
      "priority": 10,
      "isDirectory": false
    },

To

    "guava" : {
      "destination": "/opt/application/lib/guava-16.0.1.jar",
      "source": "lib/guava-16.0.1.jar",
      "priority": 10,
      "isDirectory": false
    },

Making use of automatic Parcel deactivation when activating a Parcel of the same name will fail.

Debug from the Cloudera Agent reports an error from update-alternatives.

the primary link for guava must be /opt/application/lib/guava-11.0.2.jar

Accordingly, the doc should highlight the additional importance that destination must be equal between Parcel versions (if the parcel is responsible for the alternative entry)

i.e. destination is version independent of the entry and should be static between Parcel versions.

    "guava" : {
      "destination": "/opt/application/lib/APP_guava.jar",
      "source": "lib/guava-16.0.1.jar",
      "priority": 10,
      "isDirectory": false
    },

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions