On Wed, 2017-01-18 at 09:24 -0600, Mark Hatle wrote:

I have seen other systems declare these in different ways.  Things
like:

RPROVIDES_pn += "user(name)"

RREQUIRES_pn += "user(name)"

Automation can declare provides and dependencies users that are
need.  But of course there will always be manual users/groups that
are needed as well.

You're thinking too specifically about my example. What about ca-
certificates which needs ca-certificates-native to run its postinstall
at do_rootfs time?

Keep in mind a -native dependency doesn't really make sense in a R*
namespace. This isn't really a package manager level problem but a
build system one. How do we know which -native dependencies a
postinstall needs?

Theoretically we should already be doing some of this via
dependencies today -- but it can be a complex problem.

We have some gross hacks in the system today but nothing really marks
up which postinsts need which native dependencies.

Of course this doesn't handle other things postinsts may be needed
for...

Users are really just one very special case and the problem is much
wider.

The PACKAGE_WRITE_DEPS can either be in addition to DEPENDS if the
recipe needs these tools at build time, or if its only needed for
the
postinst, PACKAGE_WRITE_DEPS can be sufficient and the DEPENDS can
be
removed.

I'm a little worried this is making things more complicated then they
may need to be.

What is the downside of simply specifying those items in the existing
DEPENDS as we have it today?  (Performance, they have to be installed
before the package can begin to build?)

DEPENDS means "this recipe needs dependencies X at build time in order
to build so they must be available by do_configure".

We could insist all DEPENDS for all recipes are installed before we run
do_rootfs but that is a significant performance issue and a large set.

With recipe specific sysroots, we've reached a point where we really do
need to know which dependencies postinstalls have IMO.

The name itself doesn't make me understand (without reading your
explanation) why it's required.  That also makes me suspect it might
be difficult (over time) to explain to people when they need this
behavior and why.

We could call it PACKAGE_POSTINST_DEPS. The issues here are that it
applies to PREINST too and that it really should list native deps, not
packaging deps. PACKAGE_WRITE_DEPS does accurately reflect where the
dependency goes and there are likely uses for this outside of
postinstalls as there are other places which have to spell out "add dep
X for deb, for ipk, for rpm).

I am hopeful that the number of places that need to reference this is
actually quite small and mostly in the core classes (like useradd,
systemd and so on). It really is a piece of core infrastructure rather
than something most developers would run into, and if they do need it,
the explains should make it clear how to use it. Code wise, the
additions are alongside the postinst pieces they apply to in the most
part.

Does that make it clearer why we need this?

Cheers,

Richard