On 07/08/11 01:26, Tim Foster wrote:
Hi Shawn,

On Thu, 2011-07-07 at 21:10 -0700, Shawn Walker wrote:
https://cr.opensolaris.org/action/browse/pkg/swalker/pkg-publish-1/webrev/

The changes look good - the only worries I have are below:

general:

I know neither of these were covered by the buglist you're fixing, but
did you get a chance to look at the rstripping of CLI args that I
mentioned?

pkgsend generate SUNWfoo/   produces different (incorrect) output to
pkgsend generate SUNWfoo

I don't recall you mentioning that, but now that I see it, I'll go fix it.

I notice that license actions are still being given 'path' attributes,
which conflicts with an existing pkglint check.

I've had to continue to let the bundle code add the attribute as the importer relies on 'path' being there.

However, I've changed pkgsend to pop the attribute off during pkgsend generate.

src/man/pkgsend.1.txt

It's not clear from the man page how publish works with the -d flag when
we're specifying a SVR4 bundle.  Does pkgsend completely ignore files in
the -d directory when processing bundles, or does it search there for
content first before choosing the content in the SVR4 package?
(from the code, it looks like we choose the -d directories first, which
makes sense)

I've added an explicit sentence documenting the behaviour.

src/pkg/pkglint_whitelist.txt

These changes aren't right.  You're correct that this was the way we
used to make pkglint shutup, but isn't the way to fix the problem now.

So what purpose does pkglint_whitelist.txt serve? The error message you get when there's a difference seems to indicate this is correct solution.

The new external dependencies should be added to
src/pkg/external_deps.pkglintrc file - a little bit premature, but
eventually we'll all hit the same new dependencies, so it's ok to add
them now.  Don't remove any entries that may be needed for systems
running the earlier non-refactored bits.

Done.

The errors about the new variants are more problematic, and really need
to be worked around by adding "pkg.linted.pkglint.manifest003.1=true"
set actions to the manifests that are reporting the errors.   The
underlying problem you're running into is bug 18673, at which point we
can remove the pkg.linted flags.

Bleargh.

Because of the super-strict way we're using pkglint in our gate, any
difference in pkglint output between the build and pkglint_whitelist.txt
is sufficient to make the build complain.

If you add the pkg.linted flags to the manifests,  we will also need to
add:

     | grep -v ^pkglint.manifest007 \
     | grep -v ^pkglint.action008 \

to the pipe that runs pkglint in src/pkg/Makefile, to ensure that the
messages that report "hey, I see you're marking an action/manifest as
linted" aren't compared to the whitelist.

Double bleargh.

I think we really ought to be using pkglint more along the lines of ON,
shipping a build-specific pkglintrc file (where we could add the
pkg-gate-specific content to our own pkglintrc file, rather than hacking
about with stdout)


All that said, if you do feel like punting on any of these
pkglint-related changes, just make sure we can build packages on snv_169
and I'll clean the rest up later.  I've already got bug 18657 open for
some build-related work that needs to happen in this area.

I've changed as above.

-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to