►
From YouTube: Working Group: 2020-09-10
Description
* Stackpacks
* Layer Origin Metadata: https://github.com/buildpacks/rfcs/pull/94
A
B
A
B
A
A
B
And
what
and
what
it's
arrived
at.
I
would
say
that
the
like
the
central
like
problem
of
the
rsa
rfc,
is
around
something
that
we're
calling
traceability,
which
is
like
tracing
like
the
inputs
to
like
a
layer,
or
you
know
at
a
at
a
higher
level
to
an
image
and
that
it's
real
that
traceability
is
related
to
reproducibility.
But
I
think
that
reproducibility
is
not
like
actually
concerned
with
identifying
inputs.
B
A
Where
reproducibility
is
sort
of
interesting
to
me
with
regard
to
the
proposal,
is
that
if
we
put
some
of
the
metadata
about
build
time
dependencies
in
the
image,
you
know
it'd
be
hard
to
reproduce
the
image
right,
and
so
I
I
like,
I
think
the
idea
is
like
with
the
report
tumble
we
can
represent,
build
time
metadata
without
putting
it
in
the
image,
so
we
don't
affect
the
reproducibility
of
the
image
of
irrelevant
things.
You
know
about
the
build
process.
Change
is
that
is
that
still
kind
of
the
path
we're
on.
B
B
B
B
B
You
know
becoming
environment
variables
might
have
some
effect
on
the
build
process
or
on
the
build
and
and
the
results
of
the
build,
but
those
you
know
like
I,
I
wasn't
taking
that
into
account
at
all,
and
you
know
even
trying
now
to
take
it
into
account
like
acknowledging
that
that
that
you
know
platform
env
exists,
you
know,
I
don't
know
how
to
deal
with
that.
You
know
it
it's
it's.
A
B
Yeah
I
mean
well
look
yeah,
so
platform
env
is
kind
of
easy
to
represent
because
it's
all
just
plain
text
stuff,
but
I
mean
I
don't
know
that
you.
I
don't
know
that
that
that
you're
restricted
you
know
in
such
a
way
that
you
can
only
mount
in
plain
text
stuff.
You
know
like
what,
if
what,
if
someone
did
like
mounted
an
executable
that
way
and
like
you
know
it
gets
it
gets
used,
I
don't
know.
B
B
Yeah
that
makes
sense
like
for
whatever
other
things
like
the
platform
might
want
to
provide
like
by
mounting
a
volume.
Another
another
example
that
was
brought
up
was
like,
like
tls
certificates
like
that
could
also
be
mounted
in
and
yeah.
Like
you
know,
if
it's
plain
text,
it's
you
know
it,
you
can
definitely
represent
it
easily.
You
know
because
it's
already
text,
but
whether
you
want
to
or
not
is
also
a
question
like.
Is
it
really
big?
B
A
You
know
like
I
guess
this
is
talking
about
build
time,
though
the
because
lots
of
you
know
secrets
come
in
via
volume
amounts
bindings
are
not,
and
because
people
sometimes
put
secrets
in
using
environment
variables,
it
seems
reasonable
to
kind
of
cut
that
out
of
scope
for
now
and
then
figure
out
a
way
to
like
you
know,
do
we
need
a
white
list
or
sorry
allow
list
or
deny
list
different.
You
know
secrets
that
come
in.
B
Yeah,
oh
it's
the
secret,
the
example
of
like
mounting
in
secrets
is,
is,
is
really
useful
like
something
that
you
would
not
want
to
represent.
Literally,
you
know
in
this
in
this
in
this
report.
Tamil,
so
I'll,
try
to
think
more
about
that
and
and
think
about,
like
yeah
sticking
with
the
the
biggest
the
biggest
pain
points
that
exist
instead
of
you
know,
trying
to
account
for
all
this.
D
A
A
I'm
looking
through
it,
the
only
things
that
kind
of
struck
me
are:
some
of
the
people
might
have
a
lot
of
feedback
on
some
of
the
names
of
things
like
application,
source
versus
source,
making
it
consistent
with
some
of
the
a
little
more
consistent
with
some
of
the
metadata
on
the
other
side.
But
but
aside
from
you
know,
minor
stylistic
stuff,
it
looks
really
good
excited
to
see
it
again.
C
A
Yeah,
I
think
that's
the
first
one
that
probably
makes
sense
to
ask.
We
know
that
the
builder
has
to
run
as
root
to
do
the
actual
build
phase.
It
came
up
when
we're
implementing
the
detect
part
of
this.
Whether
detect
should
also
run
as
root
in
this
case,
or
whether
we
want
to
restrict
that
to
not
run
as
root.
I
don't
know
if
anyone
had
any
thoughts
there
on.
A
B
A
A
C
A
A
C
I
mean
we
can
also
do
the
same
thing
where,
if
there's
no
stack
packs
it
just
that
same
thing
as
builder,
where,
if
there's
no
stack
packs,
you
just
run
detector
as
non-root
and
it's
fine
and
if
you
run
it
as
non-root,
maybe
we
just
don't
detect
stack
packs,
so
it's
sort
of
like
an
opt-in
thing.
If
you
run
it
as
root,
it
will
run
detect
for
stack
packs
and,
of
course,
if
it
doesn't
run,
detect
for
stack
packs,
they'll
never
run
in
the
build
phase.
D
I
wonder,
if
we're
being
overly
cautious
by
saying
that
the
detector,
the
life
cycle
detector
process
itself,
when
it
is
running
non-stack
pack
shouldn't
it,
should
not
be
running
as
root.
I
feel
like
the
detector
could
always
can
run
its
route
to
this
whole
thing,
but
when
it
executes
been
detect,
it
does
that
as
the
correct
user,
probably
the
most
straightforward
way
to
do
this,
and,
unlike
builder,
which
is
more
complicated
because
we're
writing
a
bunch
of
files
whose
permissions
we
need
to
be
constantly
modifying.
A
D
You
have
to
be
able
to
run
something
as
root
to
get
your
sidekicks
anyways
it's
like.
Do
we
bother
to
do
a
complicated
re-exacting
of
the
detector,
and
now
I
guess,
like
a
build
plan
merged
for
all
the
different
groups,
it
seems
a
little
bit
hard
to
me
versus
just
executing,
pin,
detect
as
a
different
user.
A
C
A
Like
we're
going
to
instantly
get
asked
to
run
as
root,
if
we
decide
not
to
run
it's
root
for
detect,
there's
going
to
be
someone
who
needs
to
read
something
they
can't
access
to
make
a
decision
like
what
I
don't
know.
I
need
to
give
some
more
thought.
We
just
thought
about
this
right
before
the
meeting.
Basically,
my
my
justification,
probably
very
weak
justification
for
saying
that
I
I
don't
think
that
would
that
would
happen
very
commonly.
C
And
furthermore,
if
there
were
a
stack
pack
that
required
special
access-
or
some
kind
of
you
know
insight
that
would
be
provided
by
the
stack
maintainer
who
would
have
control
over
the
stack
in
a
way
to
like,
potentially
make
sure
that
that
is
exposed
to
the
stack
pack.
So
if
there's
some
like
weird,
I
really
don't
even
have
an
example.
But
if
there
was
some
weird
thing,
we
could
put
it
on
the
stackpack
author
to
to
ensure
that.
D
A
A
Yeah,
the
I
guess
another
one
yeah
we
talked
about
this
I
figured.
Maybe
someone
would
know
off
the
top
of
their
head.
So
if
we're
injecting
these
stack
build
packs
into
the
detect
phase,
do
we
know
what
the
behavior
of
a
group
that
has
all
optional
build
packs?
Is
that
even
allowed?
So
if
we
inject
an
optional
build
pack
in
somewhere
in
the
beginning
of
a
group,
is
it
going
to
cause
problems
doing
it
that
way,.
A
Oh,
that's
a
good
one,
I'd
say
fail
or
do
what
we
say
now.
No
build
packs
detected
at
least
one
normal
build
pack
has
to
be.
I
don't
know,
maybe
you
just
want
to
build
a
stack
pack,
so
we
have
a
case
right
now.
We'll
give
it
a
very
specific
use
case
where
we
in
cloud
foundry,
we
had
a
bill
pack
called
the
binary
build
pack
that
was
a
no
op
and
binary
build
pack
was
kind
of
a
terrible
name.
It
really
did
nothing.
A
A
At
least
we
have
a
new
or
we
have
a
build
pad
called
the
proc
file
pack
that
we
just
put
at
the
end
by
itself
so
that
you
can
use
a
binary,
build
pack
like
use
case
with
no
build
packs
at
all
right
because,
generally
you
have
to,
we
don't
have
a
project
homily.
Yet
you
have
to
set
a
start
command
somewhere
and
so
that
that
kind
of
fills
that
nation
pretty
well
the
once
we
have
project
tamil
right
you
it's
almost
like.
A
You
really
may
want
an
empty
case
there
right
and
if
you
have
a
stack
pack,
that's
actually
doing
something
that
you
want
to
happen,
and
you
don't
want
to
be
forced
to
specify
some
other
build
pack
right.
I
think
it's
kind
of
a
larger
problem.
Is
it
valid
to
have
all
optional
in
a
group?
Is
that
valid
today?
Does
anyone
know
or
do
you
have
to
have
one?
That's
required
it?
It's
valid.
C
A
C
A
A
Well,
I
think
it's
just
a
larger,
larger
design
decision.
It's
like
what,
if
what,
if
you
do,
want
what,
if
you
you
have
a
use
case,
I
want
my
app
built
pack
to
install
this
package.
Then
I
want
maybe
this
isv
integration
to
run
and
then
that's
my
my
app
is
already
pre-compiled
and
I'm
setting
my
own
start
command
via
project
hummel
right
seems,
like
it'd,
be
a
super
common
use
case
for
some
end
users,
and
what
we're
talking
about
here
would
actually
actually
fail
that.
A
A
C
A
So
say,
look
very
concretely
say
you
want
to
install
image
magic
and
then
you
have
an
optional
build
pack
for
new
relic
and
that's
it
two
build
packs.
One
stack
pack,
one
regular
build
pack
right.
So
what
you
want
is
image
magic
to
be
installed
and
then,
if
your
app
needs
new
relic
your
valid
gets
installed.
If
it
doesn't
it
optional,
it's
optional,
so
it
doesn't
run
and
then
nothing
happens
or
you
get
image
magic
installed
and
then
your
app.
This
is
just
image
magic.
On
top
of
the
base
image
right.
C
C
I
think
we
just
need
to
handle
those
two
cases
very
explicitly
like
if
you
have
optionals,
because
what,
if
you
had
two
groups
optional
for
and
for
new
relic
and
then
an
optional
for
data
dog
or
something-
and
you
only
want
one
to
pass-
you
don't
want
the
first
one
to
pass.
So
I
think
we
just
explicitly
handle
where
the
group
has
built
packs,
but
the
only
thing
that
passed
is
a
stack
pack,
in
which
case
you
failed
the
group.
A
D
C
I
think
it
does
too.
This
is
extremely
edge
case,
though,
and
also
I
think
most
people
are
more
likely
to
put
like
data
dog
new,
relic
acme
apm
in
the
same
group.
All
is
optional,
like
that.
That's
kind
of
the
way
the
java,
the
packet
or
java
build
packs
do
stuff
right.
It's
like
a
whole
bunch
of
optional
stuff
sitting
next
to
each
other,.
C
A
Emily
brought
this
one
up
earlier
today
feature
flag
for
life
cycle.
We
talked
about
this.
All
the
life
cycle
bet
or
a
couple
of
the
binaries
will
have
new
arguments
to
deal
with
the
stack,
the
stack
group
and
the
stat
group
path,
as
well
as
the
sort
of
run
as
root
behavior.
That
is
optionally
available.
So
we're
trying
to
figure
out
maybe
how
to
get
you
know
the
next
iteration
of
this
merged
in
so
we
don't
have
to
constantly
merge
from
main
with
all
the
stuff
that's
going
to
be
going
on
there.
D
D
A
A
D
D
A
Yeah,
I
agree
I
was
just
going
to
say
it.
This
really
shouldn't
cause
a
lot
of
friction
or
like
this.
This
is
such
a
large
change.
I
think
it's
very
valuable
to
get
it
merged
in
as
soon
as
we
can.
So,
if
we're
not
like,
I
want
to
call
out
specifically
that
we
should
you
know
well,
you
know,
communicate
what
we're
doing
and
why,
if
that
makes
sense,
but
you
know
if
we
do
that,
because
it
shouldn't
look
like
you
know.
Well,
rfc
is
close
enough.
C
A
Few
checklist
items
to
do
like
you
know,
I
think
I
think
our
goal
and
joe
correct
me
if
I'm
wrong
right
now,
is
to
get
to
the
point.
The
first
merge
of
this
big
feature
set
would
probably
be
running.
The
stack
build
packs
only
in
the
build
phase
right
now
to
give
some
value
to
would
probably
extend
damage
would
probably
come
later.
Is
that
right,
joe.
D
C
A
Yeah
yeah,
I
think
this
one
is
about
when
in
the
process
do
we
need
to
validate
that
a
stack
pack
isn't
including
a
normal
build
pack
in
case
of
like
a
meta,
build
pack,
and
I
guess
the
other
question
is:
should
we
be
doing
that
and
what
does
that
mean?
Do
we
need
better
stack
packs
is
this?
Is
that
could
that
come.
C
C
D
C
D
A
C
Somewhere
so
yeah,
I
think
this
is
another
thing
that,
like
run
builder,
I
think
we
could
actually
punt
on,
but
I
think
this
we
need
in
order
to
get
for
that
first
phase
of
getting
a
pr
merged,
but
this,
I
think,
based
on
this
question
yesterday,
we
need
to
sort
out.
So
I
think
I
have
four
proposals
in
here.
One
was
a
boolean
you
just
every
provides
or
requires
the
name
could
be
a
mix
and
name
if
mixing
is
true.
C
Another
is
a
top
level
stack
provides
stack
requires
with
a
list
of
mix-ins
that
matches
other
lists
of
mixins
steven
likes
number
three,
which
is
oh
yeah,
so
each
provides
could
have
multiple
mixins
is,
I
think
that's
what
this
one
is.
I
thought
that
was
a
little
odd,
but
if
I
don't
really
care
and
then
the
fourth
one.
A
A
So
I
have
a
a
grand
unified
proposal,
type
thing
here,
with
the
build
plan
and
how
this
works.
So
one
one
thing
that's
come
up
internally
is
we
have
use
cases
where
sometimes
a
build
pack
needs
to
provide
a
dependency
and
sometimes
a
the
dependency
could
be
provided
by
the
stack
and
the
build
pack
doesn't
really
care
who
provides
it
as
long
as
it's
there
so
one
one
big
example
is
dotnet
coordinates
icu,
which
is
super
easy
to
install
without
a
package
and
can
be
just
downloaded
by
buildpack
dynamically.
A
If
you
need
it,
if
your
stack's
missing
it,
you
have
buildpack
that
installs
icu
don't
want
to
slow
down
the
build
process
just
to
install
an
icu
package.
It's
really
really
optimally
a
build
pack,
but
we
also
have
stacks
that
include
the
os
package
for
it
it's
better.
If
you
use
the
os
package,
if
it's
there
right,
so
my
my
crazy
idea
is,
you
could
make
it
so
that
the
mix
we
wouldn't
want
to
call
it
just
mix-ins
or
stack
mix-ins,
because
I
would
have
a
very
specific
meaning.
A
A
A
If
you
know
a
build
pack,
would
provide
the
dependency,
but
the
stack
is
providing
instead
do
we
does
that
provider
build
pack
fail
the
build?
Probably
not
it's
like
it's
like
the
same
case
as
if
another
build
pack
provided
the
same
dependency
name,
it
could
get
pushed
to
it,
but
it
wouldn't
then
there's
a
question
of
like
do.
We
need
a
push
mechanism,
so
the
build
plan
can
push
entries
forward
or
stack
pack
and
push
entries
forward
if
it
can't
act
during
build,
if
it
can't
actually
but
then
then
stack
packs
really
start.
A
Looking
like
build
packs
for
how
the
build
plan
works
right,
they
have
the
same
mechanisms.
There's
just
the
special
mixins
thing
that
lets
a
build
pack
claim
an
entry
by
a
series
of
mix-ins
associated
with
the
let's
stackpad
claim,
an
entry
by
a
series
of
mixins
associated
with
the
entry
instead
of
by
the
name
of
the
entry
which.
A
C
C
A
A
But
emily
is
like
proposal,
one
versus
proposal,
three
right
in
proposal,
one
you're
specifying
nixon
or
not
mix
in
very
explicitly
with
that
or
keyword
right.
You
have
to
provide
an
entirely
alternate
version
of
the
build
plan
that
has
the
mixing
version
instead
of
the
other
version
right
and
it's
a
little
it's
more
verbose
because
you
have
to
duplicate
the
whole
whole
build
plan
thing
you
want
to
care
about
multiple
times
in
order
to
do
it
right,
but
you
know
you're
you're,
I
mean
if
you
look.
B
A
The
other
example
where
you
name
the
entry
and
you
put
mexicans
in
it,
you're
still
being
less
explicit
about
it,
but
you're
still
providing
two
options:
right,
you're
saying
the
name
the
build
pack
requiring
it
has
to
say
either
name
this
or
these
mix-ins
by
putting
those
mix-ins
inside
of
it.
So
it's
not
an
automatic
interface.
It's
not
like
you
can
just
say
icu
and
then
icu
can
either
come
from
the
stackpack
or
not
right.
Maybe.
D
A
D
A
A
A
You
know
version
of
it
and
the
build
pack
installed
ones.
It's
not,
but
you
could
you
know
you
could
do
it
like
mix
dash,
okay
equals
true
as
the
field,
and
then
the
name
could
be
satisfied
by
the
next
inversion
in
the
stack
you
know
and
then
provides
could
never
under
normal,
build
tag
wouldn't
ever
say,
mixing
equals.
A
D
A
A
A
D
A
A
A
No,
I
don't
know
anything
about
icu,
okay,
that
dot
net
core
uses
icu,
and
it
can
either
come
from
a
build
pack
or
a
stack
image.
I
think
I
get
what
he
meant
by
it.
I
just
wanted
to
double
check,
so
I
think
this
works
for
that
use
case.
As
long
as
in
the
dot
net
core
build
pack
that
he's
working
on,
he
could
say
this
or
is
willing
to
do
the
build
plan
version
and
say
or,
and
then
the
mixing
version
and
repeat
the
whole
build
plan
in
case
okay.
A
D
C
C
A
C
A
But
but
one
of
the
main
things
that
I'm
I
was
wondering
about
is
there's
a
little
bit
contradictory
in
there
about
whether
the
stack
packs
are
provided
by
the
stack
author
or
whether
provided
by
the
builder
author
right
at
one
point,
there's
like
a
maybe
I
didn't
understand,
but
there
was
like
builder
tommles
how
you
add
stack,
packs
and
another
part
is
no
stack,
packs,
come
baked
onto
the
images
right
and
these
these
suggest
really
different
things
for
what
a
run
builder.
If
that
agreement.
D
D
D
The
current
proposal
mentions
the
builder
tommle,
but
it's
only
so
you
can
change
the
order
of
the
stack
packs,
which
I
think
makes
perfect
sense.
Like
stack,
packs
have
to
come
on
the
images,
but
if
you
want
to
create
a
builder
that
never
ran
the
stack
packs
or
something
you
can
do
it
in
your
builder
tunnel.
A
A
No
rebase
rebase
would
just
need
access
to
the
next
run
image
right,
because
the
next
run
image
so
like
the
way
way
how
this
works
is
the
run.
Image
always
has
the
build
pack
on
it,
but
then,
when
you
export
the
app
it
doesn't
include
the
run
image
layers,
but
on
rebase
you're,
getting
the
next
run
image,
and
so
you're
always
you
know,
should
just
always
work
so
done.
D
A
Coal
and
yeah
yeah,
that's
yeah,
I
mean
I'm
saying
I
think
I
like
that
option.
It's
it
almost
like
kind
of
brings
back
the
you
know
how
you
used
to
put
launch
true
and
build
true.
We
were
like.
Should
we
put
that
at
the
top
level,
and
we
decided
not
to
do
that,
but
but
now
it's
like
those
could
have
real
meaning
here,
right,
launch,
true
means
run
colon,
you
know
like
do.
A
We
need
to
apply,
run
colon
and
build
colon
to
build
plant
entry
names
more
generally
too,
and
is
that
the
way
that
we
get
away
with
putting
the
metadata
you
know?
Is
there
a
more
unified
system
for
doing
that
right?
If
we're
going
to
have
run
colon
and
build
colon
for
mixing
equals
true
build
plan
entries?
Should
we
have
run
colon
and
build
colon
for
not
mixing
equals?
D
D
A
Run
colon
mixing
is
no
longer
a
different
mix-in
than
just
mix-in
like
before.
There
were
different
mix
ends
and
the
label
just
specified
where
they
live,
but
with
the
relaxed,
mix-ins
rfc
that'll
maybe
get
approved
this
week
like
it's
really
irrelevant
it
just
straight
up,
it's
the
same
thing,
but
just
the
run
portion
of
it
right.
So
we
have.
We
have
more
flexibility
to
redefine
what
that
looks.
Like
you
know,
without
weird
api
related
constraints,.
A
I
I
had
one
very
last
thing
in
order
two
minutes
over,
but
one
of
the
comments
I
put
in
there
in
the
stack
pack
rfc,
I
think,
was
about
in
buildpack
tomml
the
nixon
list
that
can
be
provided.
I
think
we
need
to
move
all
that
into
the
stacks
list
and
make
it
per
stack
and
that,
like
we'll
change
the
format
at
build
pack
tama
a
lot
we
don't
have
to
like
go
into
a
lot
of
detail
now.