On Tue, May 01, 2007 at 10:54:55PM -0400, Brian Gupta wrote:
> This may be naive, but I would assume you would:
>
> 1) Download new source with fixes
> 2) Rebuild it with the same configuration options
> 3) Do a differential between the two trees, comparing:
> a) the filenames, (to see if there are any missing or new files )
> b) file checksums to identify which files changed and which didn't
> 4) Create a "patch" package, that updates the pkginfo, and contains the
> affected files
You wouldn't be creating a patch -- that's special stuff, and only applies
(currently) for Solaris 10 and prior. Don't worry about that, at least for
the moment.
You should go to
http://www.opensolaris.org/os/project/sfwnv/
and familiarize yourself with the build instructions and what little
documentation there is on contribution. The build instructions will let
you see how the rest of the consolidation is built, and give you ideas of
what this build should look like.
Given that vim is already a part of the companion and the companion build
system is identical to that of sfw, then you might want to take a look at
http://www.opensolaris.org/os/project/companion/
for what vim looks like there.
> How are builds handled between 32/64bit and x86/sparc?
Generally 64-bit builds are only done if there's a strong reason for one --
the app needs to access large memory spaces, or there are significant
performance gains, or the component is a library and some 64-bit app needs
to link against it. I don't think vim needs to be built 64-bit.
x86 and sparc builds are simply done in different workspaces.
> How are builds handled for the different sparc processor series?
Generally for userland apps we don't bother making a distinction. Just
build for sparc.
> Would I be responsible for keeping track of security alerts, or are there
> dedicated participants that monitor the appropriate lists, and notify
> package maintainers if they need to take action?
It's all you. Or anyone who happens to notice something like that and
alerts you or files a bug. It probably would be best if you monitored the
vim dev list for such things. But it probably is okay to wait until Bram
seems to have gotten a pile of patches off his chest, and integrate those.
> What are the criteria for upgrading the binary to a new version of the
> application?
When someone who wants it badly enough has the time.
> I just realized something. I am being naive. Historically Sun has not
> upreved the version of the application, but has backported "patches" into
> the existing codebase. I am not sure whether or not, rebuilidng with new
> source, or backporting fixes into "our" source is the correct way going
> forward for this application.
I'm not sure what this means. I think that if you still need to ask this
question after you've looked at the build system, you should try asking it
again then.
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
