[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Publisher question, feature requirements
- From: Pascal Rapicault <pascal@xxxxxxxxxxxx>
- Date: Wed, 14 Apr 2010 09:18:29 -0400
- Delivered-to: firstname.lastname@example.org
p2 does not make a difference between include vs require. Everything is mapped to a requirement. This is by design.
Originally in UM, this separation was here to prevent the installation of a feature if what it was requiring was not there. This was "fine" because UM was just in the business of installing extensions, but it resulted in a painful user experience since the user first had install X, then be presented with a message saying Y is missing, and repeat this process several times. Note that this was also maybe because the UM dep resolver was crap.
The other problem of hardcoding this separation in the feature is that it did not respect the consumer / producer dichotomy. For example as a producer of X you can decide that Y is a requirement, however for me (consumer of X aggregating it in Z) Y is just another part of X and I surely did not want my user to know about this "implementation detail".
Now your observation of using greed to implement the require semantics is interesting. It never crossed my mind (probably because I crossed requirements of my mind) that it could be used to that end, and at this point I'm not quite sure that this is a practice I'm ready to recommend. But again it is something that definitely worth thinking about. For example does it have the same drawbacks than previous UM constructs?
FYI last times I talked/thought about this problem I was thinking about adding a new mechanism that would allow to carry this information and would get "superimposed/applied" on the dependency graph but it never got implemented.
So is there a bug in the metadata generator for features? No, the behaviour is by design. Can it be changed? no this would break backward compatibility. Can it be improved in some ways in the future, yes.
On 2010-04-14, at 4:51 AM, Thomas Hallgren wrote:
> There are two ways of adding a feature reference in a feature. It can be either 'included' or 'required'. My interpretation has always been:
> 'included' features will be installed when the parent feature is installed.
> 'required' features serves as a prerequisite. They will not get installed. Instead, an error will be generated if they are not present.
> Is that a correct interpretation?
> If it is, then shouldn't this be reflected by the 'greedy' status of the IRequirement? From the wiki:
> "When a requirement is marked greedy (greediness flag on a requirement), installable units satisfying the requirements are added to the solution, whereas IU satisfying non greedy requirements should be added to the solution by another requirement. By default all requirements are greedy."
> To me, that sounds like a 1-1 correspondance to the 'includes' versus 'requires'.
> The reason I ask is that I cannot find any indication that this is considered in the publisher FeaturesAction. I'm not sure that my interpretation is correct so I thought I'd ask here before I file a bug.
> - thomas
> p2-dev mailing list