You made a statement about your tarball in your mail that is
disturbing. Your tarball should be the exact tarball that you pulled
down from the component's ftp or web site. If you need to apply patches
to the unpacked source, that's "ok", though we want you to file bugs for
things you are fixing with patches and submit them upstream. Hopefully,
as the component evolves, it will incorporate your changes and require
less (preferably no) patching in a future version. Specific comments
are below.
usr/src/cmd/quilt/Makefile.sfw
There is a mechanism in place that will automatically unpack your
tarball and apply all patches in
.../src/quilt/Patches/[0-9][0-9]-*.patch if you have an appropriate
dependency ($(VER)/.patched) in your Makefile. See
usr/src/cmd/{cups|ghostscript|gimp-print|hplip|top|zsh}
Are the various --with-{util} options build or runtime dependencies?
Line 73: Why are the CFLAGS different than those that you use to
actually build the bits?
Line 91: Use the $(RM) macro in place of rm "-$(RM) -r $(APP)"
usr/src/cmd/quilt/install-sfw
Lines 34-35 define an unused variable.
You might consider using the component's "install" target to
populate the proto area.
usr/src/cmd/quilt/quilt-0.47.tar.gz
This is missing from your webrev and as a result, I am assuming that
it's not under teamware control. You will need to use "wx create"
to add it to your workspace or you will end up breaking the gate if
your RTI advocate doesn't catch it.
usr/src/cmd/quilt/patch.find-path
It would seem to me that you should be generating this patch like so
that it functions like the other --with-{util} configure options and
try to submit it upstream.
usr/src/cmd/quilt/patch.guards-man
You should use pod2man to generate the man page from the perl file
during the build instead of patching this file in and having to
updated the patch with each update. If you were to use the
"install" target from the component to populate the proto area, this
would happen automatically, but it appears that the component
Makefiles may need work to honor DESTDIR.
usr/src/cmd/quilt/patch.import-zcat
This patch should be submitted back upstream. They are clearly
unpacking a gzipped file using zcat(1), where gzcat(1) is the
correct command to use.
usr/src/cmd/quilt/patch.no-bash_completion
This patch is unnecessary. You appear to be installing using an
install-sfw that is copying over bits from your build tree into your
proto area. If you had chosing to use the components "install"
target (cd $(VER) ; env - ... make ... install), you could have
removed the bits that you don't want from the proto area. Either
way, you don't need this patch and it's one less thing to regenerate
when you update this software.
usr/src/cmd/quilt/patch.refresh-z
presumably this won't go back upstream, but won't be needed if/when
we ship GNU getopts
usr/src/cmd/quilt/patch.refresh-z-test
hopefully you can file a bug and send this upstream
usr/src/cmd/quilt/patch.with-gtar
hopefully you can file a bug and send this upstream
usr/src/cmd/quilt/patch.with-xgettext
Is this something that you can send upstream?
usr/src/cmd/quilt/patch.without-patch-wrapper
Will this be accepted upstream or will a future revision no longer
need it?
usr/src/pkgdefs/SUNWquiltr/prototype_com
Line 49: is this a config file that you want to preserve on
upgrade? That they user will edit? Should the type be 'e' instead
of 'f'? Should the class be 'preserve'? Should the file be writable?
-Norm
Dean Roehrich wrote:
> I've submitted a new webrev to http://cr.opensolaris.org/~roehrich/quilt-1/ to
> integrate quilt into SFW. This incorporates the changes suggested by Paul
> Cunningham on Nov 4th.
>
> Another change: some of the patches I had in my first webrev have been
> accepted into the upstream quilt, so I've re-spun my quilt tarball and
> adjusted my patch collection. This means patch.import-mkdir and
> patch.makefile-install are no longer required, and have been removed; and
> patch.patch-wrapper has been replaced with patch.without-patch-wrapper, to
> reflect the latest discussion on the quilt mailing list.
>
> Quilt is a tool to manage a stack of patches; it's the predecessor to
> Mercurial Queues (mq).
>
> Dean
> _______________________________________________
> sfwnv-discuss mailing list
> sfwnv-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/sfwnv-discuss
>
