Michal Pryc wrote:
> Tim Knitter wrote:
>>
>> Hi Michal,
>>
>>> Hi Tim,
>>> Thanks for the webrev.
>>>
>>> I think the proposed change is fine, but it lacks one small part.
>>> Because IPS is back-published to the updates for older OpenSolaris
>>> builds and libbe is not, we will need to check weather the new function
>>
>> Starting with 2008.11 SUNWinstall-libs (libbe) is setup to be
>> back-published as well however we would like to avoid having to
>> back-publish SUNWinstall-libs each time a change is made that could
>> affect pkg(1). It would be nice if the pkg versioning work could
>> handle cross project dependencies automatically but I'm sure that is
>> slated for a later date. :-)
>
> If this is the case and SUNWinstall-libs will be back published for the
> users using 2008.05 then I'm fine with it.
I would like to avoid this if possible. We backpublished some necessary
bugfixes to make the update process from 2008.05 simpler, but we're not
planning to backpublish arbitrary features on a regular basis.
-ethan
>
>>> is available and if it is not then we will need to disable the renaming
>>> functionallity.
>>>
>>> Can we do something similar to PyGTK, so during import require the
>>> specific version of the libbe and if it is not met then we will disable
>>> the functions?
>>>
>>
>> Yes I expect something similar should be done in pkg(1) however this
>> bug only addresses the changes in the libbe space and not the pkg
>> space. 2883 should handle the changes you mention below or something
>> similar if I'm not mistaken. I wanted to get this in soon so pkg(1)
>> could detect a build version and avoid calling libbe.beVerifyBEName()
>> if that version wasn't found.
> This is something which I will leave to Brock and the guys which are
> writing api.
>
> Given what you wrote I am happy with those changes.
>
> best
> Michal Pryc
>
>>
>> Thanks
>> Tim
>>
>>> like:
>>>
>>> >>> import libbe
>>> >>> libbe.require("2")
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in ?
>>> AttributeError: 'module' object has no attribute 'require'
>>>
>>> At this stage we can cach the AttributeError as we are sure we are using
>>> old version of the libbe and we can disable the user naming
>>> functionallity.
>>> Other options are also welcome, but we do need to check if the function
>>> is available before actual using it. We could do:
>>> >>> 'beVerifyBEName' in dir(libbe)
>>> True
>>>
>>> but it would be hack rather then nice solution.
>>>
>>> Brock, as you know more about API requirements, what do you think?
>>>
>>> best
>>> Michal Pryc
>>>
>>> Tim Knitter wrote:
>>>> Ethan,
>>>>
>>>>> Tim,
>>>>>
>>>>> Just a couple more comments...
>>>>>
>>>>> BootEnvironment.py - 42 - Where is this variable used?
>>>>>
>>>> No where. I was initially going to store the max length there but
>>>> used a class variable instead. I removed it.
>>>>
>>>>> beadm.py - 193,649 - why does the '%' symbol have to be
>>>>> passed in as a variable into the error message string?
>>>>>
>>>> It wasn't possible to escape it in the message string so I had to
>>>> pass it in. Python kept interpreting it to be a format character.
>>>>
>>>>> libbe.c - 799 - should this somehow be a boolean
>>>>> function instead?
>>>>>
>>>> There isn't a way to pass back a true boolean. Or put another way,
>>>> there isn't a boolean format specifier when using Py_BuildValue().
>>>> There is the "b" specifier but when used it doesn't produce a Python
>>>> "True" or "False". It returns an int so I left this as is.
>>>>
>>>> Webrev updated.
>>>>
>>>> Thanks
>>>> Tim
>>>>
>>>>> thanks,
>>>>> -ethan
>>>>>
>>>>>
>>>>> Tim Knitter wrote:
>>>>>> Ethan Quach wrote:
>>>>>>> Tim Knitter wrote:
>>>>>>>> Hi Evan,
>>>>>>>>
>>>>>>>>> Hi Tim,
>>>>>>>>>
>>>>>>>>> I understand the reasoning behind the length limitation for the BE
>>>>>>>>> name but I'm not clear why the description is also limited to 64
>>>>>>>>> characters. What was the reasoning behind the description length
>>>>>>>>> limit?
>>>>>>>>>
>>>>>>>> None other than having a sane limit so the text doesn't wrap in
>>>>>>>> grub
>>>>>>>> and in the boot menu (menu.lst for x86).
>>>>>>> If there's no technical reason why we should be limiting this, I
>>>>>>> think we should leave it alone. What's so magical about 64 being
>>>>>>> within limits of a wrapped-around grub title anyway?
>>>>>>>
>>>>>> Nothing magical maybe a little mystical though. :-) I removed
>>>>>> description checking throughout as well as checking the length of the
>>>>>> root dataset before zfs works on the dataset later in the code as was
>>>>>> discussed in the snap meeting.
>>>>>>
>>>>>> The webrev has been updated.
>>>>>>
>>>>>> Thanks
>>>>>> Tim
>>>>>>
>>>>>>> -ethan
>>>>>>>
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> -evan
>>>>>>>>>
>>>>>>>>> Tim Knitter wrote:
>>>>>>>>>> Please review the following bug fix:
>>>>>>>>>>
>>>>>>>>>> 5749 libbe to provide public interface to validate BE name
>>>>>>>>>>
>>>>>>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5749
>>>>>>>>>> http://cr.opensolaris.org/~tsk/5749/
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tim
>>>>>>>>>> _______________________________________________
>>>>>>>>>> caiman-discuss mailing list
>>>>>>>>>> caiman-discuss at opensolaris.org
>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>>>>>> _______________________________________________
>>>>>>>> caiman-discuss mailing list
>>>>>>>> caiman-discuss at opensolaris.org
>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>> _______________________________________________
>>>> caiman-discuss mailing list
>>>> caiman-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
