Carsten Ziegeler commented on SLING-5014:

Thanks for the patch [~dsuess]

I think there shouldn't be a need to change the API to add this functionality. 
The blacklist can be checked in different places, with the patch it is checked 
more or less in the middle. I think we should either do it before or after :)
There are three steps:
- detecting a resource through the transformer - we could blacklist directly 
after this and discard the resource immediately
- state handling (this is where the patch is doing the work right now)
- task creation - we could also discard the bundles directly here and and set 
the state accordingly

> Installer blacklist, to avoid reinstalling older bundles
> --------------------------------------------------------
>                 Key: SLING-5014
>                 URL: https://issues.apache.org/jira/browse/SLING-5014
>             Project: Sling
>          Issue Type: Bug
>          Components: Installer
>    Affects Versions: Installer Core 3.6.6
>            Reporter: Dominik Süß
>             Fix For: Installer Core 3.6.10
>         Attachments: SLING-5014-1.diff
> In case a bundle has mutliple install candiates only the highest version 
> (with the highest priorty for the same versions) wins. An uninstall directive 
> in the Sling bootstrap.txt file or provisioning model uninstalls this 
> version. The way the OSGi install behavior is defined this lets the next 
> artifact in the priority queue to get active and consequently only leads to 
> downgrade to the next in the queue.
> As the uninstall directive declares a range that should be uninstalled the 
> expectation is that after a startup with such an uninstall directive none of 
> the declared versions are in an installed state. In consequence the OSGi 
> installer must save this metainformation in the state that prevents a 
> downgrade to a version that is part of an active uninstall directive.

This message was sent by Atlassian JIRA

Reply via email to