[caiman-discuss] AI and DC manifest file common items

[Kyle McDonald]

Sarah Jelinek wrote:
> Hi Kyle,
>
> Some questions answered below...
>
> Kyle McDonald wrote:
>> I know I'm not up on all the IPS lingo, and only learning now the 
>> things DC might be used for.
>> My main area of interest is AI, and my experience is with JumpStart, 
>> so I'm not sure I totally follow what you're saying here:
>>
>>
>> Stephen Hahn wrote:
>>  
>>>   If you want to ignore the group packages, that's fine--work in terms
>>>   of only the component packages.  (But I don't believe that's the 
>>> common
>>>   case.)
>>>       
>> What do group packages have to do with anything? I thought IPS didn't 
>> have groups or clusters, instead I thought it had 'Incorporations'?
>>   
> IPS will have the ability to tag packages so that we can associate 
> them with a grouping.
Ok. I thought Incorporations were more like groups, and tags were more 
like Attributes (or grouping on a different axis or dimension I guess.)

I didn't understand if Stephen had some other meaning for 'group packages'.
>
>> I definitely want to be able to say for example: 'Add all of X11, but 
>> exclude the X11 man-pages, demo's and sources.'  I want to be able to 
>> do that without having to list all the parts of the X11 'group' 
>> myself, because I don't want to be in the bussiness of maintaining 
>> that list as the definition of the group changes.
>>
>>   
> You shouldn't have to list all the members of the X11 group, but you 
> will have to list those things you want to exclude.
>
Ok. The way I read what he said was that if I wanted to exclude single 
packages, I'd need to ignore (read: not use) the group packages 
(Incorporations? Tags?) and work on a package by package basis. If 
that's what he meant, I didn't like that.

>> This is a major requirement for me. If AI can't do this, then it's 
>> not going to be of much use to me.
>>
>>   
> We plan for this. Otherwise our software management would suck! 
> Seriously, we have to provide this type of usability.  You don't have 
> to maintain the list of what is the group, you just have to specify 
> what to exclude. Which I think is reasonable from a usability point of 
> view.
>
I agree with you here, and I'm glad to hear that's  in your plan.
>>>   Image packaging will have a strict mode where installation will fail
>>>   if dependencies aren't already satisfied, but the DC shouldn't
>>>   implement an alternative dependency engine to handle an exclude-from
>>>   operation; exclude-from will potentially be expensive and likely be
>>>   fragile.
>>>       
>> What does 'Image packaging' mean here? What other modes does it have?
>>
>>   
> Image packaging == IPS.
Ok. I thought so, but It sounded like 'Image creation', so I wasn't sure 
if that meant AI, DC, or both.
>> I know the package refactoring may totally reduce the need for it, 
>> but I beleive there will still be a need in some cases to install a 
>> package and leave some dependencies unresolved. I could turn out to 
>> be wrong on that, but I know that including groups, and then exclude 
>> subgroups or packages from it. Heck I can see including a supergroup, 
>> excluding a subgroup from that, and then re-including single packages 
>> from that.
>>
>>   
> I think that IPS will make the dependency issues you might have run in 
> to less likely. We have dependencies today in our existing pkgs that 
> don't always make a lot of sense. A true dependency should be resolved 
> to install a pkg in my opinion. Because a true dependency means the 
> software wouldn't run without meeting the dependency.
>
I think the refactoring will make the biggest difference. Depending on 
the granularity we might end up with what you are describing.

However, I might want to install package foo which gives me 2 binaries 
'foo' and 'bar'. foo might run fine with the libs on my system already. 
bar might need additional libs. If I don't care about ever running bar, 
then I might not want to install those libs. I want to have that choice. 
Refactoring could split those into 2 packages to fix this, but I'm not 
sure that getting to a 1 executable per package is always the right answer.

On top of that, similiar to not wanting to have to monitor a package 
group for changes, I don't want to have new dependencies in a package 
change the set of packages that are installed silently with out my 
knowledge.

If pkg foo recompiles bar to need another lib, I want to have a master 
setting I can set to make the default 'stop the install', 'leave 
unresolved', or 'resolve automatically'. Then in the AI config, as I 
add/remove packages (or groups, or Incorporations, or tags, etc.) I want 
to  have  the option (if the master setting is 'stop the install',) to 
specify 'resolve automatically', or 'leave unresolved'.

Granted, creating my own repo, or distribution might end up making more 
sense, but I may have my own files that my finish script will install 
that will satisfy that dependency.

Eitherway, this is flexibility that I have and use now with JumpStart, 
and I can see being useful with AI at least, and possibly DC.

        -Kyle

> Regards,
> sarah
> ****
>>    -Kyle
>>
>>  
>>>   - Stephen
>>>
>>>       
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>