►
From YouTube: Working Group: 2020-06-24
Description
* Inline Buildpacks: https://github.com/buildpacks/rfcs/pull/86
* Read-Write Platform Volume Mount: https://github.com/buildpacks/rfcs/pull/85
* pack Image Pull Policy: https://github.com/buildpacks/rfcs/pull/80
* Application Mixins: https://github.com/buildpacks/rfcs/pull/87
A
A
A
A
A
A
A
A
A
A
B
A
C
A
A
Offline
build
packages,
RFC
I,
think
Dan
was
gonna.
Do
this
on
Thursday
and
present
when
he's
got
there
he's
made.
Some
changes
responded
to
a
lot
of
the
feedback
like
and
got
rid
of
the
list
somewhere
else.
It
looks
pretty
good.
There
are
some
outstanding
questions
around
it
too,
though
I
know
the
next
one
is
pack
image:
pull
policy
side
analyst.
Yes,
it's
enlisted
a
RFC
for
stack
metadata.
That's
cash
up,
I
think
he
just
responded
back
here
this
gotta.
He
added
some
examples
there
yesterday
and
it
got
approved.
A
E
A
F
E
E
It's
more
proposal
than
like
a
thing:
I
am
locking
on
of
just
maybe
some
scheming
change
stuff
to
think
about
I'm.
Just
thinking
like
it
is
actually,
even
though
they
it
is
a
bill
pack,
it
is,
to
some
degree
a
separate
concept
and
has
just
a
different
schema
of
what
is
in
the
bill,
packs
table
and
I.
Wonder
if
you
want
to
make
that
more
explicit
or
distinct
I'm
from
the
normal
thing.
E
F
I,
don't
think
we're
doing
anything
that
would
prevent
it
from
working.
So
maybe,
if
you
know
we
just
if
we
see
people
starting
to
try
and
publish
them,
we
make
it
possible.
Maybe
I
think
it'd
be
pretty
easy
for
PAC
to
use
whatever
mechanism
it
uses
for
creating
the
temporary
build
pack
and
then
do
the
same
thing
and
then
just
publish
it.
A
A
E
I
was
mostly
just
refuting
the
know
that
a
lot
of
people
come
stuff
from
Emily.
That
I
don't
think
it's
actually
inclusive,
I
guess.
The
other
interesting
thing
from
here
was
the
discussion
around
the
packs,
but
I
think
I
was
pushing
in
favor
of
white
until
refill
packs
get
finalized.
It's
probably
out
of
scope
of
this
RC.
A
This
would
let
an
app
developer
every
build
pack
that
would
break
rebasing,
Winry
pacing.
What
otherwise
work
so
like,
like
falls
into
the
large
category
of
how
do
we
do
rebuild
packs,
and
what
do
we
want
to
provide
any
guarantees?
If
any,
do
we
want
to
support
rebasing,
whether
you're
built
ax
things
like
that.
A
C
So
going
back
I
kind
of
wanted
to
pry
into
the
detection
phase,
I'm
not
proficient
in
build
packs.
You
know
at
that
level,
but
I
am
curious.
There
is
a
mechanism
that
allows
them
to
basically
specify
what
they
provide
and
what
they
require
right
for
the
build
phase.
So
is
that
not
something
that
we
might
want
from
an
inline
build
pack.
F
B
A
Also,
the
center
plays
a
little
bit
with
on
the
potato
side
they're
working
on.
They
have
a
build
plan,
build
pack
once
you
put
a
plan
Tamil
in
your
app
directory
and
require
things
from
build
picks.
So
if
you
used
an
in
line
build
pack
and
that
together,
you
could
be
requiring
stuff
and
hook
into
the
build
process
right
and
then
you
sort
of
had
that
extra
functionality.
But
if,
if
you're
able
to
do
requires
and
provides
of
things
inside
of
the
project,
tunnels
list
that
also
that
looks
kind
of
like
the
same
thing.
A
For
me,
it's
like
this
is
like
a
very
simple
restrictive
thing
that
accomplishes
some
use
cases
and
so
I'd
kind
of
support
this
moving
forward
without
like
where
detection
just
always
passes,
then
we
can
follow
up
with
more
RFC's.
If
we
like
have
additional
things,
we
think
in,
like
they'll,
Peck
should
be
able
to
do.
E
Yeah
I
guess
the
comments
that
I
made
around
detection
were
mostly
that
I
think,
potentially,
unless
you're
really
familiar
with
how
the
bill
pact
process
works
as
a
bill.
Panther
like
you,
may
not
be
aware
that
detect
Nestle
runs
in
parallel
and
that
you,
potentially
at
least
one
from
my
daugher,
fall
right
like
that.
E
You
don't
know
that,
like
like
I,
think
if
you
put
a
build
pact
between
like
say
like
after
another
bill
pact,
you
may
not
realize
that
detect
does
not
have
access
to
aim
the
kind
of
layers
or
build
artifacts
that
are
produced.
I.
Think
on
the
surface,
unless
you're
more
familiar
with
how
the
bill
packs
work
so
I
think
that
could
be
a
confusing
spare
instant
and
users
always
for
now
agree.
C
A
D
Just
an
encouragement
to
take
a
final
look
at
this.
We
are
currently
in
a
position
to
go
to
FC
p.
We
have
enough
approvals
sort
of
out
at
a
core
team.
I
specifically,
would
like
anyone
interested
in
PAC,
say
Xavier
to
give
me
one
final
blessing
before
we
actually
move
it
to
FCP,
since
it
has
changed
a
bit
and
is
directly
affecting
PAC.
At
this
point,.
C
D
It
doesn't
apply
it
basically
super
imposes
on
top
of
it.
This
is
this
won't
to
end
up
at
with
a
change
in
any
specification.
That's
currently
written
as
the
RFC
currently
stands.
This
will
be
a
feature
added
to
pack,
which
basically
will
allow
you
to
violate
the
spec.
If
you
choose
to
use
the
feature,
I
think
that's.
D
D
Well,
if
we
allow
spec
reserved
directories,
it
makes
actually
developing
build
packs
and
developing
the
lifecycle
and
developing
all
those
kinds
of
things
easier
for
us,
and
so
my
suggestion
was
to
split
the
difference
and
allow
you
to
mount
over
the
top
of
those
things
but
print
out
a
warning
that
you
were
doing
something
that
was
not
spec
compliant.
At
that
point,.
C
G
C
A
C
C
We've
talked
about
things
like
changing
the
default
to
something
like
potentially
periodic,
which
is
very
different
to
what
the
ecosystem
currently
has,
and
also
having
other
capabilities
where
we
have
more
granular
control
as
to
what
images
this
policy
applies
to,
and
that's
something
that
I
believe
others
have
asked
for
us.
Well,.
A
A
F
F
And
as
we
as
we
were
going
through
that
it
like
I,
started
to
feel
like,
we
were
just
solving
those
problems
and
we
weren't
really
focused
on
solving
the
problem
for,
like
the
end
user
right
like
we
were
building
cool
tech,
so
I
took
like
a
total
step
back
after
we
did
some
spitballing
last
Thursday
using
a
concept
called
stack
pack.
That
is
just
funny
that
I
keep
coming
up
with
different
variations
of
the
name
bill
pack,
but
the
interface
is
very
different.
F
It,
like
stack
packs,
actually
borrow
quite
a
bit
from
the
route,
build
pack
concept,
except
that
they're
a
little
less
end-user
facing
so
the
interface
that
we
want.
I
think
I
think
everybody
kind
of
greed
with
this,
but
the
interface
that
we
want
for
the
end
user
is
more
like
mix-ins.
So
why
not
double
down
on
mix-ins
and
allow
applications
to
define
their
own
mix-ins?
And
so
that's,
basically,
what
I'm
proposing
in
this
RFC?
F
That's
really
simple.
The
rest
of
it
is
how
that
works.
That's
just
the
complicated
part
and
how
it
works
is
essentially
a
stack
pack.
So
builders
will
ship
can
ship
with
a
type
of
build
pack
that
runs
this
route
and
it
runs
against
the
stack
and
it
doesn't
have
to
the
application
code.
So
it's
only
job
in
life
is
to
mutate,
the
stack
or
to
extend
or
enrich
the
stack
I
guess
rather
so
this
is
a
bunch
of
detail
in
here
about
how
that
works.
F
Then
we
don't
want
the
use
of
that
third-party
build
pack
to
sort
of
override
or
shadow,
though
all
the
orders
that
might
include
stack
pack
is
optional.
So
I
was
wondering
if
we
wanted
a
separate
like
order
like
construct
specifically
for
stack
packs.
That's
one
of
them.
The
other
was
if
we
wanted
to
define
types
for
mix-ins,
which
I
thought
I
had
sketched
some
of
this
up,
oh
yeah.
F
F
The
other
open
question
was
about
upgrades
I'm,
not
sure.
If
we
want
to
have
stack
packs,
be
required
to
be
a
bi
compatible
or
X
declare
that
they
will
keep
ABI
compatibility
or
just
not
at
all,
and
just
some
of
the
questions
around
that
yeah
and
here's
an
example.
So,
let's
open
up
the
discussion,
that's
kind
of
the
gist
of
it.
A
Very
logistically
for
type
the
the
reason
I
proposed
the
pattern-matching
or
like,
like
you,
just
use
reg
X
for
it,
as
opposed
to
like
you
know
something
more
explicit.
Is
that
the
concept
that
the
spec
defines
mixin
very
loosely
and
the
concept
of
set
versus
package
that
we've
defined
for
the
Bionic
stack
is
just
to
flick.
A
little
vial
in
extent,
isn't
codified
in
the
spec
anywhere
and
so
adding
adding
right.
So,
like
your
solution,
is
exactly
what
I
thought
at
first,
like
oh
yeah.
A
This
is
how
different
types
of
nixon's
that's
pretty
simple,
but
it
actually
doesn't
work
with
how
we've
defined
mixin
so
far
and
so
I
went
to
say.
Well,
you
know
any
name
that
doesn't
have
an
equal
sign
in
it
or
whatever
is
how
the
app
build
tag
works
for
Bionic,
because
we've
defined
bionics
such
that
equal
sign
is
a
special
character.
That
means
you're
not
talking
about
talking
about
some
other
concept:
you're,
not
talking
about
just
a
package
name.
So
if
that's
helpful
for
explaining
the
motivation
behind
the
regex
solution,
that
I
proposed
yeah
I.
F
Mean
is
it
so
loose
that,
like
I
I
settled
on
this
in
part,
because
I
was
reading
the
bionic
mix-ins
RFC
again
and
that's
where
it
says?
Basically,
if
you
don't
you,
if
it
doesn't,
have
an
equal
sign,
it's
a
package
I
think
that's
what
it
says
right,
which
is
why
I
settled
on
this,
but
then
I
wasn't
thinking
about
it
being
specific
to
the
Bionic
stack,
so
I
mean.
Is
it
possible,
for?
A
I
think
the
problem
or
what
I
would
worry
about
is
if
the
bill
pack
requests
a
set
and
the
set
isn't
fulfilled
my
stack,
then
that
set
would
get
sent
to
the
apt,
build
pack
and
then
a
hat
build
pack
would
try
to
apt-get,
install
it
and
and
I
think
the
right
behavior
in
my
head.
The
right
behavior
should
be
that
build
pack
doesn't
like
like
specifies
it.
In
its
you
know,
detection
filter
right
that
it
it's
only
able
to
provide
packages.
It's
not
able
to
provide
sets,
consider
what
would
happen
if
sorry,
so.
F
A
I
mean
like
that's
what
I
did
in
the
red
jacket?
That's
the
best
way
to
do
it,
but
another
case
to
think
about
is,
if
you
had
multiple
stack
packs
and
one
could
provide
sets
and
the
other
can
provide
packages
being
able
to
say
you
know
this
can
provide
set
equals
star,
and
this
can
provide
anything.
That's
not.
An
equal
sign
would
be
really
clean
way
of
saying
here's
a
here's,
a
bill
package
that
can
actually
provide
a
set
right
like
maybe
you
wanted
to
create
you're,
not
operating.
A
A
For
Bionic
its
defined
somewhere
that
they
have
to
be
for
the
ID
io
bill
packs
tax
Bionic.
They
have
to
be
an
app
package
for
other
static
IDs.
They
they
don't
have
to
be,
but
because
the
app
stack
pack
could
be,
we
could
produce
one.
That's
just
certified
for
Bionic
or
just
certified
for
stacks.
That
also
use
that
convention.
It
all
kind
of
clicks.
G
I
think
it
does
I
still
think
there
might
be
room
in
there
to
accidentally
like
bring
in
another
stack
pack,
that
sort
of
like
super
seeds
and
other
snack
packs
installation,
because
it's
so
loose
it's
just
a
string.
It
doesn't
really
like
someone
else
could
get
in
there
and
provide
it
and
provide
like
if
you
asked
for
curl
and
then
something
else
like
it
does
a
more.
But
you
know
star
name
filter
just
like
app
does,
and
then
it
installs
its
own
curl
and
then
app
doesn't
get
to
install
it.
B
A
A
A
It's
currently
done
with
notation,
that's
specific
to
the
biotic
stack
that
I'm
not
sure
if
we
want
to
make
more
general
based
on
how
to
find
a
current
spec,
and
so
that
it
would
need
a
lot
more
thought
about
what
what
types
mean
and
how
you
encode
them
in
mixin
names,
and
if
we
need
to
make
a
break
a
change
in
the
mixin
format
as
it's
written
on
stacks.
All
that
stuff
make
me
regret,
not
come
not
making
it
not.
Complaining
that
makes
sense
should
be
a
list
of
objects
instead
of
a
list
of
strings.
F
Koya
I
also
haven't
actually
submitted
the
RFC
yet
so
happy
data
work
through
that
I
think.
The
thing
that
worries
me
more
is
the
how
the
stack
pack
makes
its
way
into
the
order
like
I
said:
I'd
really
like
it
to
be
a
little
bit
different
from
the
order,
such
that,
if
you
are
using
a
group
that
doesn't
have
the
stat
pack
and
then
you
want
the
mixin
or
something
like
that,
you
don't
suddenly
have
to
understand
this
whole
new
stack
pack
construct
right.
It
just
sort
of
works
if
you're
stacked.
A
As
a
strawman,
what
if
we
always
made
all
the
stat
packs,
participate
in
detection,
no
matter
what,
if
they're,
on
the
stack
for
ever
and
there's
no
way
to
configure
them?
What?
Where
does
that
break
down,
given
that
the
next
sensor
like
it
or
this
typing,
doesn't
have
to
provide
again?
Where
does
it
break
down.
F
A
Don't
have
a
strong
opinion
I
like
the
idea
that
if
we
provide
configure
ability
to
be
outside
of
order,
like
you
know
like
you
described,
but
I
also
can't
think
of
any
reasons
why
we
should
provide
the
functionality
to
disable
them.
So
because,
like
the
only
thing
I
think
of
is
as
an
app
developer,
you
never
want
packages
to
get
installed
dynamically
and
you
want
it
to
fail
if
they're
not
present
on
the
stack.
A
B
B
A
F
G
B
C
So
I'm
curious
about
the
maybe
performance
implications
where
we
think
about
the
mix
ins
as
the
thing
that
gives
you
like
a
very
early
failure
if
things
aren't
compatible.
But
now,
since
we
have
like
this
catch-all
or
fallback
where
then
it
has
to
go
check,
the
stack
PACS.
Is
there
something
that
I
miss?
That
is
preventing
that
cheque
from
happening
like
a
pattern
matching.
C
A
C
I
guess
I
was
just
thinking
whether
or
not
if
there
was
a
way
to
like.
If
you
have
mix
ends
right,
and
you
know
that
you
know.
Basically,
if
the
stack
pack
could
provide
a
pattern
that
says,
I
only
respect
things
that
are
prefixed
with
you
know
apt
for
the
sake
of
argument
right,
then
you
don't
like.
If
you
know
that
up
front,
then
you
don't
have
to
actually
execute
the
detection
phase.
I.
A
Think
that's
what
I
was
trying
to
say.
Also
it's
like,
because
we've
made
it
so
that
that
pattern
is
output
dynamically.
During
the
detect
process,
we
can't
prove
a
ledee
tit
and
I'm,
not
sure
why
it
needs
to
be
executed
dynamically
during
the
detect
process.
If
nothing
can
you
know,
we
can't
see
a
different
app
directory
yeah.
F
F
B
G
B
Stacks
they're,
attempting
to
put
together
has
no
chance
of
ever
succeeding,
as
opposed
to
kind
of
like
putting
them
together.
Seeing
it
fail
is
missing
it
mixing,
trying
again
consume
that,
for
the
apt
provides,
it
doesn't
really
need
to
be
dynamic
right
and
also
the
requiring
of
a
mixing
in
the
project.
G
C
I
guess
that's
where
the
pattern
matching
sorry
I
was
gonna
say
like
I
guess,
maybe
that's
why
I
was
maybe
proposing
a
pattern
matching
of
some
sort.
If
you
had
a
way
to
say
like
these
things
can
be
dynamically
provided
versus
the
you
know,
or
there
is
something
that
could
dynamically
provide
something
like
this
right,
then
you
could
still
have
that
check
be
dynamic,
but
within
certain
confines
that
you
know
ahead
of
time.
F
A
So
because
the
stack
packs
can
only
provide
mix-ins
and
because
other
build
packs
can
only
require
mix-ins
I
thought
that
the
mix-ins
table
in
the
build
plan
would
actually
be
sufficient
because
you'd
never
be
like.
You
know,
there's
never
actually
a
conflict,
it's
just
it's
always
just
mix-ins
and
I
mean.
A
F
B
F
C
B
F
Feel
pretty
fast,
I
mean
yeah,
I,
agree
well,
I'm,
not
sure
I.
Guess
I'm
not
settled
on
how
much
I
want
to
like
use
the
term
stack
pack
as
like
anything
part
of
this
spec.
You
know,
I
mean
so
that
part
I
hesitate
on
also
like
go
pack
Tamil
doesn't
have
to
be
named.
Phil
pack
Tamil
like
you
can
pass
it
fubar
Tamil.
If
you
want
so
the
naming
it
I'm,
not
convinced
as
sufficient
I
think.
C
A
You
know
you
could
imagine
stack
pack
square
stack,
build
packs
where
every
call
and
being
published
to
the
registry
being
distributed.
You
know,
will
be
less
of
them
and
it's
it's
a
different.
They,
you
know
serve
some
different
functions
right
but
like
I
not
opposed
to
them
being
build
packs
in
that
greater
sense,
I
don't
know
if
I
would
call
them
I
would
make
the
switch
privileged,
if
that
makes
sense,
cuz
that
maybe
implies
a
little
bit
less
than
what
it
means.
Maybe
it's
like
stack.
F
A
F
A
F
And
that's
the
thing
we
were
saying,
like
all
the
constraints
we
were
putting
around
them
was
starting
to
a
road
that
original
idea
and
get
us
away
from
the
problem
era
kinda
solve,
but
we
want
where
you
talked
about
like
well.
If
people
just
keep
asking
for
it
after
we
give
them
mix-ins,
maybe
that's
something
we
need
to
tackle.
G
A
Contractually,
if
you're
on
Bionic
you're
not
allowed
to
make
a
pure
mixin
name
feelin
like
a
predefined
stack
ID,
its
stack
packs
like
make
us
that
they
enforce
the
contracts
right.
You
can
always
break
the
rules
as
much
as
you
want,
but
then
the
thing
is
that
stack
packs
will
do
like
to
say
free
bait
like
replay.
We
bases
and
things
like
that
or
you
know.
Suddenly
you
know
you're
you're
on
your
house.
A
To
think
about
this,
but
I
think
there
are
aspects
where
the
stack
tag
does
imply
must
imply
a
bi
compatibility
moving
forward
because
you're
gonna
replay
it
on
the
run
image
and
then
use
that
reuse.
The
same
top
layers
before
you
do
the
rebase,
and
so
the
changes
you
made
must
all
the
code
linked
must
continue
to
link
right,
and
so
there's
definitely
aspects
of
this.
Where
you
stack
pack
must
guarantee
a
bi
compatibility,
because
we're
explicitly
saying
force
tag
backs
rebasing
does
work
right,
yeah,.
F
E
F
B
F
A
F
F
B
A
Bad
way
right
because
you
could
say
like
these
things
aren't
included
in
the
launch
image,
but
also
they
also
come
back
during
the
build,
in
the
case
that
it's
not
and
that's
how
that's,
how
you
can
implement
and
that
was
so
separate
from
idempotent,
which
is
like.
Does
it
rebuild
on
the
previous
image
or
not
right,
it's
very
different
from
does
it
recover
excluded
pieces
next
time,
I
think.
F
A
It
could
either
be
a
separate
cache
or
you
could
recover
the
kind
of
I
like
the
cleverness,
the
awkward
cache
that
exclude
this
piece
and
also
it
means
that
you
can
bring
it
back
next
time
from
rebuild
packs,
but
also
it's
definitely
harder
to
understand.
Then,
like
here's,
a
thing
that
gets
restored
every
time
in
the
same
place.
B
F
A
F
A
B
A
That's
kind
of
what
I
was
saying:
you
can
either
do
the
awkward
cache,
that's
kind
of
clever
and
you
know,
has
sort
of
layer,
reusability
benefits
or
you
can
just
provide
a
separate
directory
that
gets
restored
every
time.
Right,
I,
don't
have
a
strong
opinion,
but
but
I
did
propose
a
separate
directory
in
the
original
one
smell.
B
B
B
C
B
E
Wonder
if
there's
in
my
classic
put
my
rust
at
on
thing,
but
they
have
the
concept
with
cargo
for
build
like
release
profiles
or
like
basic
profiles
that
basic
have
the
default
side
of
configuration.
So
you
can
have
like
potentially
non
idempotent
and
privilege
does
come
primitives
I
guess
then
you
mainly
could
set,
but
then
there's
like
a
stack
profile
that
sets
a
bunch
of
stuff
for
you
and.
E
E
So
imagine
for
most
users
right,
like
I'm,
not
thinking
about
like
if
I'm
building
a
stack
pack
I'm,
not
thinking
about
like
that.
This
is
privileged
true
or
that
like
non
idempotent
or
whatever
right,
like
I,
probably
actually
at
any
day,
just
want
a
stack
back
like
don't
make
me
think
about
that.
I
have
to
set
these
with
two
other
flags,
so
I
get
that
functionality
right.
C
F
Yeah
I
wonder
if
the
top-level
key
well
I
don't
know,
maybe
that's
not
any
better
than
changing
the
file
name,
but
if
you
could
use
that
top-level
key
as
a
mutually
exclusive,
it's
a
stack
pack
root
pack
build
pack
kind
of,
but
that's
somewhat
limiting
to.
If
you
ever
want
to
put
more
behind,
like
you,
don't
have
multiple
profiles:
hey.