Hi Evan,
I think I've now got everything in place. I don't see where I'm
touching the makefiles with a path to /usr/share/auto_install; I actually
don't see any makefile in the gate which has the text
usr/share/auto_install. I'm only seeing this in the pkg prototype which
can't use the makefile rules; otherwise, I've cleaned the makefile which
generates publish-manifest to do that symbolically and bug 4402 should
handle pathnames in Python symbolically.
Thank you,
Clay
On Mon, 9 Mar 2009, Evan Layton wrote:
> Hi Clay,
>
> There's a couple of comments below. Other than that I think for the most part
> this looks OK.
>
> -evan
>
> Clay Baenziger wrote:
>> Hi William,
>> Comments inline. New webrev at
>> http://cr.opensolaris.org/~clayb/6166/webrev2.
>>
>> Thank you,
>> Clay
>>
>> On Fri, 6 Mar 2009, William Schumann wrote:
>>
>>> Clay,
>>> pkginfo.tmpl NAME= looks like a package name and it should be a short name
>>> for humans to read.
>>
>> I agree. SUNWauto-install is:
>> NAME="SUNW-automated-installer"
>> But SUNWinstall (and most others) are much nicer with something like:
>> NAME="System install libraries and commands"
>>
>> I've changed both SUNWauto-install and SUNWauto-install-common to be better
>> formed.
>
> It appears that the name is still something like
> "SUNW-automated-installer-common" I thought this was to be changed to
> something more descriptive. Something like "Automated installer Common
> Components" or did I misunderstand this comment?
>
>>
>>> I thought that new package names were not going to be prefaced with SUNW.
>>> Please check current policy on new package names.
>>
>> I've pinged Dave and Sanjay for clarification and direction. I'm unaware of
>> any new policy, but that's likely just ignorance.
>>
>>> Seeing publish_manifest.py in the review with Makefiles makes me wonder if
>>> we should start using symbolic references to common pathnames in Python.
>>> Consider making a Python constant with the same name as in
>>> Makefile.master: ROOTAUTOINST= $(ROOT)/usr/share/auto_install
>>
>> I'm thinking you want what has been talked about as bug 4402 - Pull fixed
>> strings in A/I server python code out to a separate module. Is that
>> correct?
>
> It doesn't look like 4402 was originally referring to these Makefile
> changes to add these common paths. If we're talking about doing these
> makefile canges anyway why not start that with this change? I guess
> this is more of a nit but if it's not too much additional work maybe
> we should do this now.
>
>>
>>> All new files: update copyright year. Doesn't hg nits report this?
>>
>> It does, my apologies for not having run hg nits. I'm now hg nits clean.
>>
>>> Please document the new package dependency chain in bugzilla - just a few
>>> lines to help visualize.
>>>
>>> William
>>>
>>> Clay Baenziger wrote:
>>>> Hi William,
>>>> Can you look at this webrev for 6166? I think it achieves what you
>>>> were hoping to do with a new SUNWauto-install-common. I've updated the
>>>> files which seemed affected and tested the server. I'm deferring 6280
>>>> until after this release, as it'll be a lot of change I think.
>>>>
>>>> Webrev:
>>>> http://cr.opensolaris.org/~clayb/6166/webrev/
>>>> Bug:
>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6166
>>>>
>>>> Thank you,
>>>> Clay
>>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
>
