Ok, here is the scenario I am concerned with...

our intrepid open source developer decides to start with snv_86 that he 
downloaded from Sun's website.

He goes to opensolaris.org, downloads and installs the hg package.

He goes to opensolaris.org, and hg clone's a distro constructor 
workspace. He uses one of the sample .conf files that shows

COMPRESSION_TYPE=lzma

and then runs

./build_dist.bash test1.conf (for example)

and now things go bad, because he doesn't have SUNWclofi on his machine, 
so lofiadm complains and I think we are done.

Now, if our intrepid developer had started using the RC0 cd, he would be 
fine because SUNWclofi is there. SUNWclofi isn't on preview2, I don't 
think, or on a "stock" snv install either.

I think there is a hidden hard dependency on SUNWclofi being on the 
build machine or distro constructor may die.

I could be wrong. If I am, please educate me.

Channing

Jean McCormack wrote:
> Channing Lovely wrote:
>> Ok, so you cleaned up the verbiage saying that the intrepid user must 
>> use a compression algorithm supported by lofiadm. How is our intrepid 
>> user supposed to know that? The lofiadm man page only talks about 
>> gzip. So, at this point we are distributing DC code that is using an 
>> option that is not legal per man pages, and if our public audience 
>> follows the instructions on "getting started with distro constructor" 
>> and try to build themselves, it will die. There is some breakage 
>> here, not sure where it needs to be addressed.
> Why will it die? gzip is fine. lzma is fine even if the man pages 
> don't say so.
>
> Jean
>>
>> The code changes are fine, with the caveat noted above.
>>
>> Channing
>>
>> Jean McCormack wrote:
>>> Dave Miner wrote:
>>>  
>>>> Jean McCormack wrote:
>>>>   
>>>>> Addresses:
>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=1125
>>>>>
>>>>> Webrev:
>>>>> http://cr.opensolaris.org/~jeanm/distro_constructor/
>>>>>
>>>>>       
>>>> A couple of things:
>>>>
>>>> - It would be nice if this also allowed gzip-9, since lofiadm 
>>>> allows that to be used as well
>>>>
>>>> - Relatedly, I'd rather we didn't duplicate lofiadm's error 
>>>> checking of its command-line parameters, since this creates another 
>>>> place that needs changing if and when lofiadm acquires additional 
>>>> compression.  You could pass this through to a dummy lofiadm 
>>>> invocation to let it validate, perhaps.
>>>>
>>>> Dave
>>>>     
>>> I've updated the webrev.
>>>
>>> Jean
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>   
>>
>


Reply via email to