Thanks for drawing my attention to this Tim, I'm behind on this list. Ethan Quach wrote: > 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. :-) >>> I'm not sure what you mean by handling cross project dependencies in this context. >> 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. > I think I'm a bit confused. SUNWinstall-libs is going to be back published, but that back published package won't always contain the latest bits? Or sometimes it will be back published and sometimes it won't? My guess is David C. or someone else in IPS knows what's going on better than I do in this space, but I was a bit confused by what you said here. > -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. >> >> My suggestion for this case is to simply make the call to libbe.beVerifyBEName and catch any attribute error which results and disable the functionality. I think this might be the simplest thing for everyone involved. If the interfaces start undergoing large, incompatible, revisions then I think a versioning system might make sense. If you need to check this functionality at startup Michal then we can add that functionality to the API as well.
My only question about the code is whether it would be possible to not define the max BE name length in two different places. It might be necessary, but things like that make me slightly nervous. Other than that, the changes as is look fine to me. Thanks for taking care of this Tim. Brock >> best >> Michal Pryc >> >> [snip]
