►
From YouTube: Working Group: 2021-06-09
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
Today,
happy
here
is
that,
are
you
volunteering
cool
any
new
faces?
I
don't
think
so.
The
company's
been
here
before
release,
planning
and
updates.
B
A
C
B
It
also
seems
like
just
a
lot
of
active
discussion
still
yeah
just
need
to
go
on
the
agenda
this
week.
B
Good
next
one
is
make
build
layers
read
only
for
subsequent
build
packs,
looks
like
this
one
needs
some
more
approvals,
see
how
many
status
update
on
this
one
anything
you're
looking
for.
D
Just
so,
I've
not
read
through
emily's
comments,
yet
I
think
last
time
in
one
of
the
meetings
we
were
discussing
some
alternates,
I
think
terence
brought
up
the
fact
that
this
would
currently
silently
fail
like
if
some
build
packs
were
expecting
to
modify
layers
from
another
pack
rather
than
giving
them
any
warning
or
error
message.
We
just
discard
those
changes
which
would
be
sudden.
A
D
As
far
as
I
can
see,
this
would
apply
to
existing
buildback
apis
as
well.
Like
there's
no
change
on
the
api
side.
It's
just
the
life
cycle,
discarding
those
changes,
so
that
was
the
one
question
we
had
is
whether
we
want
to
calculate
the
the
digest
for
each
of
the
layers
and
then,
if
they
change
between
buildbacks
through
a
warning.
B
Make
build
layers?
No
sorry
that
was
talk
about
blocked
and
setting
default
command
arguments
that
can
be
overwritten
by
the
user.
This
is
blocked
on
larger
changes
to
processes.
I
think
emilio's
going
to
open
a
new
rfc
anything
else
on
this
one.
This
week,
cool
disambiguate
layer,
metadata
files
have
metadata
files.
B
This
yeah
yeah
I'm
taking
over
on
this.
I
got
some
information
from
emily.
A
B
Sounds
great
and
that
concludes
our
rfc
review,
so
we'll
jump
over
to
announcement
the
so
we're
moving
this
working
group
meeting
to
10
a.m.
Tomorrow,
10
a.m,
eastern
time
on
thursdays
to
kind
of
better
support.
Folks,
in
other
time
zones.
B
C
C
And
I
know
that
this
discussion
is
about
maybe
potentially
changing
the
format.
I
would
think
that
if
we
wanted
to
post
it
onto
the
newsletter,
we'd
want
to
do
it
when
those
changes
are
formalized.
B
A
Draft,
I
just
ask
a
question:
are
we
keeping
the
office
hours
on
thursday
as
well,
so
we're
going
to
have
two
meetings
on
the
same
day?
Okay,
great.
Thank
you.
D
D
D
D
I
think
one
of
the
open
questions
was
like:
what
do
we
gain
from
having
a
structured
format
versus
what
do
we
lose
from
the
current
freeform
metadata
table?
That
bomb
is-
and
I
think
one
of
the
points
that
came
up
was
whether
we
even
want
to
do
something
like
this.
D
So
currently,
there
are
like
a
lot
of
fields
that
existing
belt
backs
put
into
the
bomb
they
would,
if
they're,
not
generating
these
bombs
from
a
pre
like
from
an
existing
tool,
they
would
have
to
figure
out
where
these
things
would
go,
and
that
may
be
harder
for
the
buildback
authors
to
figure
out
like
mappings
between
where
their
fields
currently
are
and
where
they
would
end
up
going.
So
for
the
pochetto
case,
it
was
things
like
the
dependency
source,
uri
and
sha.
D
I
think
I,
like
I
wrote
down
some
solutions.
So
currently,
cyclone
dx
has
a
free
form.
Key
value
store,
called
properties
available
for
almost
any
component
in
the
s
bomb.
So,
like
things
like
components
or
the
top
level
metadata,
almost
everything
has
the
free
from
properties
table
which
would
which
could
be
used
as
a
substitute
for
this.
D
The
other
question
that
came
up
is
what
happens
when
like
when
you
want
to
convert
between
different
formats
like
if
there
is
a
one-to-one
mapping
between
the
different
sperm
formats
and
if
information
would
be
lost.
D
So
I
think
one
of
the
alternatives
proposed
was
for
buildbacks
to
have
its
own
internal
bom
format,
which
would
then
map
to
the
various
other
bomb
formats
that
exist
in
the
wild.
I'm
not
sure
how
I
feel
about
that,
because
then
we'd
be
inventing
a
n
plus
one
bomb
format
that
we
would
be
responsible
for
converting
into
the
other
end
formats
and
figuring
out
the
mappings.
For
so
not
too
sure
about
that.
D
I
think
the
other
question
that
came
up
was
like
the
format
of
the
bomb
itself.
So,
as
we'll
be
creating
these
bill
of
materials,
the
there
are,
since
there
is
a
lot
of
existing
tooling
and
these
tools
output,
a
fairly
large
form.
D
We
can
no
longer
like
put
it
on
like
the
label
as
we
currently
do.
So
we
have
to
store
it
in
some
file.
D
Now
the
the
option
is
to
store
it
as
it
is
in
the
launch,
tremolo
layer
dominance,
but
that
might
break
how
like
these
bombs
are
represented
because
things
like
spda,
x
or
cyclone
dx
have
their
own
s-bomb
documents
and
they
expect
the
scheme
of
that
document
to
look
a
certain
way.
So
then
we'll
have
to
figure
out
a
mapping
between
these
documents
and
the
bom
table.
D
We
have
in
the
layer
tumble,
so
my
proposal
was
to
separate
it
out
into
a
different
file
into
entirely,
which
would
which
would
either
be
xml
or
json
leaning
towards
json,
because
that's
the
sort
of
format
that
a
lot
of
bomb
generation
tools
in
the
while
support
I've
not
seen
a
single
tool,
support
tommle.
So
unless
we
really
really
want
everything
to
be
internal
and
like
have
well
packed,
authors
convert
jason
to
tommel
and
vice
versa.
D
My
suggestion
was
to
like.
Currently
it
was
to
just
allow
authors
to
just
put
it
in
xml
or
json
format
and
then
for
the
life
cycle
to
just
store
it
and
merge
it.
However,
it
wants,
but
I
think
the
conversation
was
that
it
should.
We
should
pick
one
which
is
jason
and
leave
the
responsibility
of
conversion
to
the
author,
and
I
think
the
other
question
was
whether
we
want
to
merge
the
bombs
produced
by
different
layers
and
the
launch
terminal,
which
was
around
like
whether
we
want
separate
layer
level
bombs.
D
As
far
as
I
can
tell,
we
currently
already
merged
the
bombs
from
different
places
and
we
could
still
have
a
unified
bomb
merged
from
different
layers
or
launch
dominance,
but
just
indicate
where
it
came
from
to
point
to
the
origin,
which
I
think
is
sort
of
what
one
of
the
poquito
buildback
library
does.
I
think
lip
back,
maybe
which,
where
it
inserts
the
layer
id
or
the
buildback
id
in
the
bom
as
metadata.
So
I
think
we'll
just
be
porting
over
that
concept.
D
But
it
is
still
useful
to
have
a
single
bomb
for
the
container
image,
because
that
is
typically
what
a
lot
of
containers
scanning
tools
that
do:
cv,
detection
or
license
detection
taken.
D
The
last
bit
of
a
question
that
may
concern
platforms
is
currently
we
use.
D
The
rfc
in
its
draft
state
propose
a
cyclone
dx
as
the
the
the
bomb
format
that
things
would
be
stored
in
because
it
looks
like
it's
more
extensible
and
there's
more
tooling
around
it,
especially
more
go
tooling
that
can
that
can
be
used
directly
without
shelling
out
to
something
so
it.
The
current
rfc
puts
the
owners
of
converting
between
different
warm
formats
onto
platforms
or
their
helpers
allies.
D
Similarly,
the
only
other
platform
that
I've
interacted
with
kpac
has
a
capex
cli,
which
has
a
similar
kpak,
inspect
image
or
inspect
bom
sub
command.
So
I'm
imagining
either
pack
could
provide
a
reusable
library
that
either
already
uses
one
of
the
existing
libraries
that
converts
between
different
bom
formats
and
maybe
adds
some
build
back
specific
flavorings
on
top
of
it
if
needed,
otherwise
like
they
could
just
reuse
the
bomb
conversion.
Libraries
that
are
present
in
the
wild,
so
the
that's
the
current
state
of
this
rfc
there
was
a.
D
There
was
somewhat
of
a
tangent
here
on
container
scanning
as
a
whole,
which
I
don't
think
we
want
to
go
into
because
that's
like
a
that's,
either
a
post
build
step
or
like
even
if
it's
live,
which
what
don't
currently
support.
I
don't
think
that
exactly
fits
into
how
currently
buildbacks
own
the
bomb
and
that
they
are
stand
alone,
as
opposed
to
having
a
separate
tool
running
at
the
same
time
that
mounts
the
volume
and
tries
to
scan
things.
D
So
I
I
don't
think
I'll
I'll
prefer
moving
in
something
like
an
external
tool
that
does
form
generation.
So
that's
where
my
current
thoughts
are
on
this
rfc.
B
I
think
I'm
100
on
the
same
page,
I
build
packs,
generate
cyclone
dx
during
the
build
process,
put
the
cyclone
dx
into
cyclone
dx
formatted
files
and
then
maybe
have
the
lifecycle
hydrate,
those
files
with
more
information
about
the
layer
name
and
the
build
pack,
and
all
that
this
sounds
really
good.
I
agree
about
turn.
B
You
know
it's
for
scanning.
Whole
containers.
Build
packs,
may
need
a
tool
to
scan
language
modules
if
they
don't
want
to
try
to
you
know
parse
package,
json,
lock
or
whatever
themselves
right.
It
doesn't
seem
like
that's
turn,
but
there
are
tools
to
do
that.
So,
like
everything,
the
only
small
comment
I
have
is
you
mentioned
the
layer
being
too
large.
Sorry,
the
label
being
too
large
for
cyclone
dx.
B
We
have
we
kind
of
have
this
problem
already
and
it's
kind
of
a
problem
and
kind
of
not
a
problem,
so
the
config
there's,
no,
the
config
blob
is
stored
in
the
registry.
As
a
you
know,
like
a
file
system
player,
there's
no
limit
in
oci
for
how
large
it
can
be.
It's
okay
to
make
a
extremely
long
label.
There
isn't
really
a
problem
in
specification
for
it,
but
some
cades
clusters
with
some
you
know,
there's
like
one
little
bug
in
container
d
right
somewhere
that
you
know
creates
some
edge
cases
where
it's
bad.
B
So
I
think
we,
regardless
of
whether
we
do
this
or
not.
We
already
have
that
problem.
Our
bomb
is
already
too
long
for
those
those
cases
and
so
I'd
kind
of
recommend
taking
that
into
a
different
rfc.
I
think
I've
talked
to
emily
or
somebody
about
this,
where
we
probably
need
to
support
a
different
label
for
long
bombs.
B
That
kind
of
indicates
no
don't
look
in
the
label.
Look
in
this
layer,
that's
appended
onto
the
end
of
the
image
or
something
like
that,
or
maybe
in
a
different
image.
I
don't
know
but,
but
I
might
take
that
out
of
this
discussion
because
I
think
it's
equally
applicable,
regardless
of
whether
we
make
the
change
or
not.
I
wouldn't
I
wouldn't
like
let
that
block
moving
forward
on
this.
I
think
we
could
even
approve
this
and
say
yep.
It
goes
into
the
config
blob.
D
I
think
in
the
last
working
group
meeting,
it
was
explicitly
called
out
that
we
won
that
change
in
this
rfc,
given
that
this
would
open
up
buildback
authors
to
use
a
lot
of
better
tooling,
which
would
generate
larger
bombs
that
they
might
currently
do,
and
this
this
is
a
problem
that
doesn't
come
during
the
build
time.
Right
like
you,
can
still
push
these
things
onto
your
registry.
D
It
pops
off
later
during
run
time,
and
the
idea
was
like
we
may
be
putting
in
this
rfc,
which
would
cause
a
change
which
would
have
authors,
try
and
create
better
bombs
and
then
later
on,
discover
that.
Okay,
all
of
these
images
that
we've
created
with
these
large
labels
are
killing
their
gates
cluster.
So.
B
B
A
D
Be
appropriate
to
call
it
out
in
this
rfc
that
that's
a
problem
and
when
this
is
implemented,
the
sibling
rfc
should
also
be
implemented.
At
the
same
time,.
C
Yeah
I
was
gonna
ask:
is
there
a
point
of
contention
right
now
with
the
moving
of
the
bom
metadata
into
a
file
format,
or
is
it
just
to
keep
it
a
cleaner
discussion.
B
D
B
How
is
that
layer
referenced
from
the
other
label?
You
know
is
that
by
diff
id
is
it
by
you
know,
digest
the
layer
probably
makes
the
most
sense.
You
know
it
doesn't
need
to
be
multiple
layers.
If
we're
going
to
split
the
you
know,
if
we
have
a
build
time
and
a
runtime
one
should
the
build
time
would
be
in
there.
You
know
if
it's
a
file,
what
should
the
file
be
called?
B
C
Okay,
yeah
cause,
I
think,
two
of
the
questions
I
had
kind
of
leaned
into
how
that
would
be
implemented.
So
I
think,
maybe
just
for
reference
into
that
separate
rfc,
the
two
questions
that
came
to
my
mind
where
I
know
in
the
past,
we
talked
about
potentially
having
some
other
things
outside
of
build
pack
specific
things
that
may
be
in
the
base
image
and
how
this
would
work
with,
like
rebates.
Right
we'd
have
to
replace
that,
potentially
in
a
rebase
scenario,
that
layer
with
the
s-bomb
information,
if
it
does
have
base
image
information.
C
The
other
thing
I
had
in
mind
was
I
I
get
that
it's
going
to
be
stored
in
a
layer
but
from
a
platform
perspective.
I
think
it'd
also
be
nice
to
be
like
some
sort
of
output,
in
the
same
way
that
the
report
tunnel
is
so
that
we
can
have
it
as
a
thought
without
having
to
then
go
pull
down
a
set,
another
layer
or
the
layer.
Yet
again,
if
that
makes
sense,
so
those
two
little
things.
A
I
have
one
clarifying
question
and
then
another
question,
so
I
I
from
everything
that
I've
read
and
everything
that
I
feel
that
I
understand
about
this.
The
the
idea
is
to
get
rid
of
the
current
bill
of
materials
fields
inside
of
build
and
launch
correct,
like
build.com
on
launch,
like
we
wouldn't
have
those
anymore
there'd,
be
no
more
existing
tamil
table
of
build
materials.
Is
that
correct?
A
Okay,
cool
that
that's
the
clarifying
thing
that
I
wanted?
The
the
follow-up
that
I
have
is
I'm
fine
with
picking
cyclone,
dx
or
spdx
or
whatever
I
do
have
concerns
about
the
are
the
ability
to
actually
easily
convert
between
the
two
and
how
lossy
it
has
the
potential
of
being
so.
I
I
have
some
concerns
about.
I
think
part
of
the
reason
I
was
one
of
the
maybe
potential
proposers
of
we
have
our
own
table,
and
then
we
do
our
own
internal
conversions,
which
I
agree
feels
really
bad.
A
So
I
don't
want
to
come
out
here
and
say
that
we
should
definitely
do
it.
But
I
do
have
some
concerns
about
potentially
putting
ourselves
on
like
an
island,
because
I
think
that
makes
us
less
accessible
to
people
that
are
doing
these
like
security
and
compliance
scans,
because
a
lot
of
them
are
limited
by
the
tooling
and
limited
by
their
ability
to
change
what
tooling
they
use.
And
so,
if
we
don't
support
the
correct
format,
I
have
concerns
that
we're
going
to
just
not
fulfill
their
use
case
at
all.
B
D
It
it
can
be
converted
without
loss.
The
the
issue
is
finding
the
right
mappings
without
loss,
in
the
sense
that,
like
there
are
obviously
things
in
cyclone
dx
which
can't
be
converted
to
spdx
like
these
freeform
tags,
they
would
probably
go
in
some
random
annotation
comments
in
spdx,
which
are
not
that
structured.
D
So
there's
a
way
of
preserving
information,
whether
that
information
is
correctly
scanned
by
the
following
tools
is
a
separate
matter
for
like
really
popular
pieces
of
information
like
licenses
the
version
and
the
package
name
itself.
Those
are
mapped
and
defined
by
the
nd
ia
working
group.
So,
like
the
the
major
things
that
these
scanners
would
look
for,
are
sort
of
mapped
any
additional
information
you
put
in
on
top
of
that,
that
is
like
cyclone,
dx,
specific
or
spdak
specific
may
be
lost,
because
there
is
no
defined
conversion
between
the
two
fields.
B
Could
we
define
a
like?
I
don't
know
you
could
call
this
a
almost
a
subset
of
of
cyclone
dx,
where
the
some
of
the
arbitrary,
like
you
mentioned,
the
properties
hash.
Some
of
the
arbitrary
fields
are
defined
in
the
build
packs
case
and
build
packs
should
use
specifically
named
fields
inside
of
that
for
writing
things
like
what's
the
shot
of
the
binary
url.
What's
the
source
url,
you
know
things
like
that.
If
we
define
those
up
front
in
the
project,
then,
ideally
those
would
get
converted
in
a
predictable
way
over
to
spdx.
B
And
so
then
we
could
say
here's
what
it
looks
like
in
cyclone.
Here's
what
it
looks
like
in
spdx
convertible
between
the
two
formats.
We
have
fixed
fields
that
everything
can
parse
all
the
build
pack,
things
look
the
same,
and
it's
very
unlikely
that
we're
in
a
position
where
we're
not
supported
by
some
tool
because
who's
going
to
choose
something:
that's
not
cyclodex
or
as
pdx.
Hopefully,.
D
One
thing
I
do
want
to
note
is
like
some
of
the
mappings
are
predefined
like
well
not
predefined,
or
have
been
defined
by
the
community
at
large
between
spd
x-speed
and
cyclone
dx.
We
should
keep
that
and
try
to
map
it
to
some
of
the
existing
fields
used
by
a
popular
buildback
so
that
they
have
a
migration
path.
But
I
don't
know
if
I
feel
very
strongly
about
like
putting
a
style
guide
on
top
of.
D
The
properties
thing
in
the
spec
we
discussed,
having
like
a
best
practices
thing-
maybe
that's
a
more
appropriate
place
to
put
it
so
that
people
have
a
common
reference,
but
I
don't
think
it
should
go
in
the
spec
and
it
should
really
be
left
up
to
the
black
authors
and
also,
if
we
put
it
in
the
best
practices
place,
then
we
can
update
that
recommendation
based
on
what
tooling,
like
what
community
tooling
is
actually
using.
D
If
you
put
it
in
the
spec.
The
conversion
processes
but
like
changing
the
spec
is
a
lot
harder
to
do
than
changing.
B
D
Like
other
reports
now,
although,
as
the
bellbacks
project
we're
mostly
just
on
the
creation
and
possibly
transformation
side,
we
should
be
aware
of
the
consumption
as
well
in
order
to
make
these
decisions
like
what
what's
best
and
that
landscape
is
huge
and
wild
and
there's
no
community
consensus
even
outside
of
the
well
patch
project
on
like
what's
the
best
xyz.
B
You
just
mean,
like
you,
know,
forrest,
you
got
a
bunch
of
fields
in
your.
You
know
build
pack
tommles
for
potato
project
right.
Can
we
get
those
you
know
into
the
discussion
in
the
rfc,
so
we
can
talk
about
what
things
we
might
want
to
standardize,
just
just
in
a
very
constrained
case
of
what
people
are
using
it
for
right
now,.
A
That
is
a
good
example
of
that.
But
for
the
most
part,
I
I
don't
know
how
I'm
conflicted,
because
if
it
doesn't,
if
it's
not
an
important
field
inside
of
a
bill
of
materials
standard
that
already
exists,
maybe
it's
not
an
important
field
for
actually
accomplishing
what
needs
to
be
done
with
the
bill
of
materials.
A
D
This
this
rfc
is
is
from
when
I
started
researching
into
this,
like
it
has
grown
a
lot
and
even
the
community
consensus
around
the
standard
bomb
format.
Isn't
there
like
and
there's
also
a
lot
of
like,
I
think
politics.
Surprisingly,
us
government
politics
are
influencing
small
formats
a
lot
right
now,
as
well,
because
of
the
executive
order
and
the
landscape
is
changing
quite
dramatically.
D
It
has
in
the
last
couple
of
months.
So
I
don't
know
if
you
want
to
wait
for
all
of
that
dust
to
settle
down
and
then
pick
one
or
should
we
just
roll
with
it
now
and.
C
I
think
I
guess
my
take
would
be
to
answer
some
of
the
the
questions,
the
open
questions,
one
by
one
and
see
which
ones
still
stand
like.
I
think
the
the
one
about
a
custom
format.
I
know
forrest
you
kind
of
voiced
your
your
opinion
on
that
one,
but
I
am
curious
how
that
would
solve
anything
or
mitigate
some
of
the
data
laws
once
you're
translating
from
let's
say
that
format
into
cyclone
dx
you're
going
to
have
to
figure
out
where
to
put
it
in
cycle
of
dx
right.
C
So
if
we,
if
we
do
that
as
a
you,
know,
superset
and
have
some
sort
of
defined
fields
of
where
you
could
find
something
as
important
as
like
the
source
url,
then
we
already
have
something
that's
closer
to
already
consumable
by
third
parties.
That
then,
can
be
translated
to
something
else
based
on
those
guidelines
or
best
practices
that
we
kind
of
set
up
right.
A
I
think
I
think
in
sam-
maybe
you
mentioned
this-
I
think
the
only
and
maybe
we
answer
this
part
as
well.
The
only
problem
is,
then
you
become,
you
become
a
spec
chaser
at
that
point
where,
as
they
update,
you
have
to
constantly
be
chasing
and
making
sure
that
your
fields
stay
in
sync,
which
is
it
could
be
a
good
thing
or
a
bad
thing.
I'm
not
going
to
make
any
pass
any
judgment
on
it
right
now,
but
it
definitely
adds
that
overhead.
C
D
Because
of
like
because
of
the
early
2021
incidents
and
then
like
u.s
government
deciding
that
everything
that
they
use
must
have
in
this
bomb,
so
everyone's
trying
to
figure
out
the
drawbacks
of
different
formats
and
trying
to
fix
them,
so
cyclone
dx
released
we
1.3
this
year
after
one
and
a
half
years.
I
believe
I
think
1.2
was
released
in
2020
or
2019.
D
I
don't
remember,
I
think
a
lot
of
these
questions
might
be
better
answered
by
like
the
specific
office
hours
we've
set
up
with
steve
from
the
spd
explore
project,
and
I've
also
asked
if
someone
from
the
town
project
who
deal
with
spd-x,
a
lot
could
be
involved
so
that
we
have
both
the
sides.
The
spectrum.
C
And
I
mean
just
to
step
back
a
little
bit.
I
think
where
we
are
now
is
we
probably
have
the
worst
option
right?
We
have
this
like
very
arbitrary
s,
bomb
thing,
bill
of
materials
that
sometimes
doesn't
even
fit
in
the
labels,
and
so
things
crash,
so
anything
right,
whether
it
be
cyclone,
dx
or
spdx,
would
be
better
than
the
current
situation.
And
if
we're
talking
about
a
year
and
a
half
to
two
year,
turnaround
where
we
might
have
to
change
something,
it
sounds
reasonable
to
still
go
forward
with
it.
B
I
would
be
happier
with
this
if
this
rfc
said
we're
going
to
use
cyclone
dx,
we'll
merge
everything
together
and
then
we'll
figure
out
how
to
get
the
data
format
looking
better
in
the
future,
because
I
still
think
it
would
be
less
you
know,
or
it
would
be
more
useful
than
what
we
have
you
know
right
now
and
how
we're
writing
into
the
images.
So
I
agree
like
I
think
we
should
have
the
discussions.
B
I
think
the
work
you
know
office
hours
with
people
who
know
they're
talking
about
is
great
but,
like
you
know,
very
pro
moving
forward
quickly
with
you
know,
picking
a
format
and
you
know
making
decisions
using
the
information
we
have
and
then,
if
we
need
to
change
something
later
coming
back
on.
B
C
B
D
Something
I
put
in-
and
I
was
just
curious
about,
like
the
existence
of
slash
players
and
why,
like
different,
build
backs,
have
like
things
they
put
into
separate
layers
and
why
it
gets
copied,
as
it
is
to
the
image
like
the
the
only
question
I
had
is
what
like,
what's
stopping
like
life
cycle,
as
it
is
right
now
from
taking
everything,
that's
under
the
build
like
layers,
buildback
id
blah
and
putting
that
as
an
overlay
with
that
exact
part.
D
B
It's
really
painful
if
the
paths
change
between
build
time
and
run
time,
because
it's
it's
the
old,
build
pack
api
kind
of
did
this.
It
didn't
lay
it
out
into
slash
user
bin
or
slash
bin
or
whatever
it
didn't
move
the
files
that
way,
but
staging
happened
in
slash,
temp,
slash,
workspace
or
something,
and
then
all
the
files
were
copied
into
the
home
directory
at
the
end,
and
the
changing
pads
meant
that,
like
a
lot
of
scripts
had
to
you
have
to
have
like
processes
that
run
at
runtime
that
rewrite
a
bunch
of
scripts.
B
A
B
A
big
simplification,
so
that's
one
reason
I
think
not
having
the
directories
overlap
like
not
getting
the
build
packs
the
bin
directory
that
the
previous
build
pack
had
access
to.
You
know
part
of
that's
like
kind
of
a
security
thing.
Almost
you
want
these
isolated
things.
Some
of
it's
influenced
by
next
next
looks
very
similar,
and
then
it
kind
of
creates
these
isolated
directories.
I
think
eventually,
I'd
like
to
see
a
layer
like
there'd,
be
like
maybe
a
package
format
for
a
layer.
It's
pre-packaged
like
that
right.
B
D
Know
those
were
like
the
exact
reasons
I
could
imagine
like
this
came
up
because,
like
like
some
of
the
use
cases
around
like
stack,
packs
or
like
putting
things
under
certain
directories
may
possibly
be
solved
if
buildbacks
could
write
into
something
during
build
time,
and
that
would
be
mounted
oh.
That
would
be
mounted
after
separate
route
during
runtime,
so
that's
sort
of
where
my
thoughts
were
coming
from
like.
Why
did
we
choose
to
go
this
way
as
opposed
to
the
other
one?
I
do
get
the
build
time
and
runtime
changes.
D
B
D
B
D
Okay,
it
can
totally
imagine
the
consequences.
I
I
I
just
wanted
this
like
on
the
record
for
my
own
information,
like
what
the
drawbacks
are.
I
I
I
was
thinking
about
some
similar
ones,
but
I
wanted
like
some
history
from
people
who
are
involved
in
the
original
decision,
just
to
sort
of
lay
it
out
more
concretely.
Why
we
can't
do
this
and
why.
A
D
D
Back,
I
think
the
the
main
question
was
like
how
would
shared
layers
work
for
older
platform
apis?
I
think
that
was
one
open
question
and
the
I
think
one
other
question
that
terence
had
was:
should
we
be
putting
these
shared
layers
under
like
a
buildback
id
namespace?
D
I
think
those
are
probably
the
standing
items.
I
don't
know
if
jesse
or
emily
or
terence
have
any
emily,
isn't
you
but
jesse
or
terrence.
If
you
have
any
open
questions
on
this.
A
D
I
I
think,
like
my
original
motivation,
behind
putting
the
types
there
explicitly
was
what
emily
was
saying
that
for
a
way
for
us
to
differentiate
between
whether
we
explicitly
wanted
that
thing
to
be
cast
like
there
was
the
rfc
a
while
ago
on,
like
setting
all
of
these
to
false
on
each
rebuild.
D
The
motivation
was
along
some
other
lines,
since
this
was
a
build
only
layer,
the
only
other
flag
I
could
think
of
was
cash
so
to
to
figure
out
whether
this
would
cache.
A
A
Oh
cute,
there,
I
guess,
along
with
these
flags,
is
there
can
other
build
packs,
modify
that
layer.tumble
file.
D
No
it
it's
currently
like
unless
the
the
build
pack
that
created
it
exposes
it
through
an
environment
variable,
they
won't
be
able
to
the
only
that
specific
buildback
who
created
this
layer
would
be
responsible
for
cleaning
up
or
resetting
things.
D
I
think
this
was
a
compromise
between
each
build
pack
dumping
in
metadata,
which
they
they
may
or
may
not
be
aware
of
versus
the
original
buildback
being
responsible
for
populating
all
the
metadata
from
from
things
that
have
been
dumped
by
other
buildbacks.
So
I
think
at
the
end
we
decided
it's
fine
to
have
metadata,
but
we
assume
that
the
metadata
here
is.
A
A
D
Putting
in
the
metadata,
but
then
I
don't
know
how
that
would
work
with
caching,
because
when
you
do
a
rebuild,
how
would
that
build
back
know
whether
like
like,
if
it
checks
for
the
things
that
originally
created?
I
will
now
know
that.
B
B
A
I
mean,
but
even
like
a
build
cache
right,
like
you
probably
want
to
know
like
abi
compatibility
or
whatever
of
like
versions
that
are
putting
stuff
in
there.
A
What
do
you
mean
like
you,
can
imagine,
for
instance,
like
a
compiled
program
like
go
or
java
right,
where
I
don't
know
why
you
would
share
the
thing.
Maybe
you
have
a
bunch
of
build
packs
interact
with
it
and
but
it
never
ends
up
in
the
launch
image.
So
you
would
put
it
as
a
shared
thing,
and
you
can
imagine
wanting
to
store
information
on
that
cache
right,
but
you
can
already
use
a.
B
A
B
Yeah,
I
can't
think
of
specific
use
cases
where
I
would
want
metadata
associated
with
the
multi-writer
layer,
but
if
they
exist,
it'd
be
good
to
you
know,
make
sure
we
account
for
them.
D
A
D
A
D
D
Well,
not
exactly.
There
were
a
couple
of
reasons
why
they
are
name-spaced
one
to
clean
up
things
when
the
original
buildback
is
removed
into
so
that
there's
no
like
and
other
build
pack
won't
randomly
go
and
blow
up
the
entire
shade
layers.
Cache
like
it
like.
If,
let's
say
bill,
pacquiao
created
a
layer.
D
The
way
it's
currently
proposed,
it's
it's,
the
the
end
directory
under
buildbacks
is
a
special
directory
which
the
lifecycle
looks
into
to
export
the
environment
variables.
Everything
else
is
fair
game
for
them
to
create.
B
A
we
remove
one
level
of
nesting
essentially
like
have
shared
layers
and
then
escape
build
pack
id
and
then
just
end
directly
under
that,
and
then
not
not
force
people
to
use
the
layers
structure
within
their
packs.
You
know
cache
directory
like
because
the
layers
aren't
very
special
here
right.
They
don't
there's
nothing
special
about
the
contents
of
them
besides
and
you
wouldn't
want
their
environment
variables
to
overlap
because
one
would
override
the
other
anyways
like
it
feels.
A
B
D
I
currently
kept
the
domino
files
for
like
the
explicit
cleanup
and
putting
some
random
metadata
if
required,
we
couldn't
remove
that.
The
the
other
thing
was.
This
means
that,
whatever,
like
all
of
these
things,
are
cached
together.
So
if,
for
whatever
reason,
you
have
a
common
cash
flow
pack
that
sets
up
a.
D
Are
cached
and
invalidated
together.
B
But
the
alternative
would
be
they
have
these
files
next
to
them,
and
the
build
pack
has
to
change
those
files
to
uncache
them,
but
the
build
pack
can
already
uncache
them
by
just
deleting
the
directory
right.
I
don't.
I
don't
see
a
big
difference.
A
B
A
Yeah,
that's
it's
the
same
thing
as
layers
that
new
change
right,
where,
like
they
have
to
opt
in
to
keep
that
that
layer
that
shared
cache
layer
for
each
one.
So
if
you
potentially
move
it's
the
same
reason
why?
For
at
least
whether
we
do
the
name
space
or
not
like
that
file
exists
for
the
same
reason
that
you
argued
for
the
other
one
for
normal
layers.
B
I
think
that,
or
that
makes
sense
to
me
why
it's
important
to
call
it
each
layer
individually,
because
we
want
the
build
packs
to
be
able
to
opt
into
each
layer
getting
created
individually,
but
you
can
move
end
to
the
top
because,
like
out
of
the
individual
layer,
namespace
and
then
just
keep
each
layer
as
a
scratched
thing,
if
you
wanted
to
because
they
can't
shouldn't
the
environment,
variable
shouldn't
overlap.
I
I
really
get
a
drop
to
my
next
thing.
Oh
sorry,.