On Wed, Nov 05, 2008 at 12:20:01PM -0600, Norm Jacobs wrote:
> In general, we have been taking the community tarballs and applying
> patches to them, even when the patches are things that are in the
> community SCM repository, but newer than the tarball. This makes it
> clear what we have applied on top of the base foo-### component.
Okay. I'll roll it back and revive some patches.
> >For those CRs that I open for the patches, when should those CRs be closed?
> >
> >Do open CRs prevent me from doing a putback into SFW?
> >
> If you have opened up the CRs in the component's bug tracking system and
> supplied the patches upstream, that's all we can ask.
So you're not saying I need to open CRs in Sun's internal bug tracking system,
but that the issues need to be reported to the upstream community.
> >> Are the various --with-{util} options build or runtime dependencies?
> >>
> >
> >Would you elaborate?
> >
> My question was do you need /usr/gnu/bin/XXX during the build, on the
> installed system for quilt to use at runtime, or both? Based on one of
> the packages, it would appear that they are at least runtime dependencies.
They are used at runtime.
> >>usr/src/cmd/quilt/install-sfw
> >>
> >> Lines 34-35 define an unused variable.
> >>
> >
> >The comments should mention only those variables that I actually use?
> >
> If you aren't using them, delete them.
Done.
> >>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.
> >>
> >
> >The regular quilt 'make install' step does not attempt to run pod2man, or
> >to install the guards manpage.
> >
> >Today this patch creates quilt-0.47/doc/guards.1. Instead of that, I could
> >modify the 'install' target in Makefile.sfw to run:
> >
> > (cd $(APP); \
> > /usr/perl5/bin/pod2man bin/guards.in > doc/guards.1)
> >
> I would prefer to see it generated from the perl file so that it matches
> what they supply without having to re-patch at the next upgrade.
Good, bin/guards (should have said bin/guards, not bin/guards.in) is the perl
script in question.
> >>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.
> >>
> >
> >No, on linux machines 'zcat' is GNU zcat. And they don't have or need a
> >thing
> >called gzcat.
> >
> sigh. gzip used to be installed under several different names (gzcat
> being one of them) on Linux. Apparently I missed the memo. You might
> use "gzip -dc" and try sending that upstream, which should be more
> universal than assuming that zcat(1) on any system supports lz77 (gzip)
> compression.
I'll take a look at reworking the test case.
Dean
