►
From YouTube: CNB Sub-Team Sync: BAT: 2021/12/03
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
Just
a
reminder
for
those
who
haven't
already,
there
is
a
document
attached
to
this
meeting.
Please
do
sign
in.
A
B
Yeah,
I'm
a
developer
at
google
and
I'm
working
on
the
cloud
run
cloud
functions
and
app
engine
products,
specifically
I'm
focusing
on
some
stuff
with
build
packs.
So
that's
why
I
joined
this
meeting.
A
Great
nice
to
have
you
here,
I'm
somber,
you
can
call
me
sam,
I'm
one
of
the
maintainers
on
the
buildpacks
project
and
yeah.
I
guess
we
can
go
around
and
introduce
the
rest
of
the
people
in
this
world.
C
I
can
introduce
myself,
I
don't
know
if
I've
ever
joined
this
meeting
before
I've
been
in
some
other
cnb
working
group
meetings,
but
my
name
is
sophie.
I'm
a
developer
working
at
vmware.
I
currently
am
working
on
paquetto
build
packs,
so
an
implementation
of
the
cloud
native
build
pack
spec
and
I'm
a
maintainer
on
the
keto.net
core,
build
packs,
our
ruby,
build
packs
and
our
tooling
and
most
recently
are
stacks
now.
So
I
thought
I
would
join
today
say
hey
to
everyone.
A
Okay,
I
think
I
can
go
next,
I'm
also
working
on
vmware
and
the
buildbacks
team.
This
is
my
first
meeting
with
the
pacquiao
and
buildbacks
authors.
A
C
I
guess
I'll
go
next,
I'm
gabe!
I
am
a
developer
at
bloomberg.
I
work
with
sambhav
and
naden.
We've
been
working.
I've
been
working
internally
on
some
buildbacks
things,
and
this
is
also
my
my
first
meeting
here
so
nice
to
meet
y'all.
B
Hi,
I'm
aiden,
I
work
with
sambhav
and
gabe,
although
they
might
be
at
different
places
on
your
monitor
and
yeah
right,
build
packs
internally
on
the
team
that
maintain
our
internal
stacks.
I
end
up
using
a
lot
of
the
pacquiao
stuff,
so
thank
you
very
much
for
all
that
and
we
modified
to
our
own
ends
internally,.
B
Hi
I'm
forest.
I
work
on
vmware
on
the
piketto,
build
packs,
yeah
building
out
all
your
favorite
picado
build
packs.
B
What
is
what
is
pikado.
B
Open
source
vendor
neutral
cloud
native,
build
packs
implementation
project,
so
we
implement.
A
Yeah
we
we,
as
a
project,
have
three
sort
of
suggested
builders.
There's
the
google
one,
there's
the
picato
one
and
there's
the
heroku
one
on
pack
I
mean,
but
it's
nice
to
see
people
from
both
the
sides.
Here,
it's
the
first
time
we
have
had
someone
from
google
participate
in
one
of
these
meetings.
It's
really
nice
to
have
you
here.
A
There
were
a
couple
of
batch
releases
of
lip
cnb
that
went
out
mostly
fixing
a
few
bugs
and
enforcing
the
enforcing
the
s
form
format,
with
the
actual
things
that
people
are
writing.
This
is
so
that
we
catch
it
early
on
in
lip
stnb
and
not
later
on
in
the
life
cycle,
when
it's
actually
a
result,
so
that
people
who
are
doing
unit
tests
using
lipscnb
know
beforehand,
if
they're
doing
something
wrong
thanks
daniel
for
both
of
those
patches-
and
I
think
that's
pretty
much
it
we
are.
A
A
C
No,
I
think
you
summarized
it
pretty.
Well,
oh
actually,
probably
the
only
thing
we
still
don't
have
the
pack
release
out.
I'm
not
sure
how
other
people
feel
about
that.
I
don't
mind
using
the
rc
for
for
testing,
but
I
feel
like
it's
probably
gonna,
make
it
take
a
little
while
longer
before
people
actually
start
using
the
s-bomb
stuff.
We've
put
into
a
lot
of
our
build
packs.
A
Yeah,
I
think
the
only
thing
stopping
the
actual
release
is
this
life
cycle
patch
we're
just
hoping
that
that
goes
out,
and
we
can
include
that
as
the
default
lifecycle
version.
In
fact,
before
we
ship
out
a
release.
A
There's
one
more
standing
item
rfcs,
but
meanwhile,
if
you
have
any
other
items
on
the
agenda
that
you'd
like
to
add,
please
go
ahead
and
do
that.
I
am
going
to
add
cnv
2.0,
because
it
might
be
nice
to
discuss
that
with
a
wider
audience.
A
Sure
yeah,
let
me
just
pull
up
the
screen
and
talk
about
what
we
do
here
in
terms
of
rfcws.
So
all
all
the
new
features
that
go
into
the
buildbacks
project
must
go
through
an
rfc
process.
A
In
this
specific
meeting,
we
look
at
rfcs
that
relate
to
features
that
may
impact
buildback
authors,
so
anything
tagged
with
the
built
by
causality
tag
most
recently,
the
the
these
are
like
some
of
the
recent
rfcs
that
do
have
impact
on
buildback
authors.
I
think
we've
covered
most
of
them
in
the
last
few
meetings.
There
have
been
a
few
updates
to
the
iran
images
from
one
and
there's
a
new
rfc
here
to
replace
the
the
positional
arguments
to
the
build
binary
in
favor
of
environment
variable
ones.
A
So
maybe
we
can
just
talk
about
that
briefly,
I
I
don't
know
how
much
in
you
know
the
pocket
folks
have
been
working
a
lot
on
the
spam
stuff
for,
but
for
those
of
us
who
are
new
to
ds
form
implementation
in
buildbacks,
we
recently
immersed
in
a
bunch
of
things
to
allow
buildbacks
to
output
a
bill
of
materials
in
some
standard
formats.
These
include
spda,
cyclone,
dx
and
sift.
A
This
is
to
ensure
that
build
packs
can
create
these
bill
of
materials
during
the
build
time,
as
opposed
to
scanning
it
later
from
the
output
image
which
may
be
in
which
may
be
less
accurate
than
what
you're
creating.
If
you
know
all
the
build
time
dependencies
that
are
going
into
your
image
so
that
I
have
seen
implementation
solved
it
for
all
the
buildback
layers,
but
we
still
don't
have
anything
for
the
run
image,
so
this
rfc
tries
to
solve
it
for
the
run
image.
A
I
think
this
specific
rfc
still
leaves
out
the
emerging
part,
but
tries
to
address
putting
the
s
bomb
in
a
way
that
still
works
across
three
basis
fairly
quickly.
A
A
I
think
the
main
points
of
discussion
on
this
rfc
right
now
is
how
you'll
attach
this
image.
This
has
formed
to
the
image
without
mute
with
concerns
like
this
will
mutate
the
image
or
like
how
will
you
identify
the
diff
id
of
the
previous
layers,
while
attaching
the
test
bomb,
because
it
requires
the
run
run,
images
from
to
be
and
the
diff
id
of
that
layer
to
be
present
as
a
label
on
the
output
image.
A
So
the
main
points
of
contention
were
like
that.
This
cannot
now
be
done
in
a
single
dockable.
Then
you
need
a
specialized
tool
or
sub
command
under
pack
to
attach
this
as
form
and
update
the
base
image
to
reflect
the
specification,
I
think
that's
what
we
were
discussing,
but
if
anyone
has
any
updates
for
any
better
ideas
on
how
we
can
attach
theorem
images
from
that,
please
leave
comments
on
this
rfc.
C
I
feel
I
haven't
been
able
to
join
the
working
group
meeting
in
a
few
weeks,
and
I
know
that
this
has
been
a
discussion
for
a
while,
and
I
was
just
wondering
if
any
like
viable
alternatives
to
what's
been
discussed
in
the
rfc
are
becoming
like
front
runners,
because
I
haven't
seen
that
much
like
written
in
the
rfc
and
or
in
the
conversation
about
like
what
alternatives
are
being
considered.
If
any.
A
But
yesterday
in
the
common
working
group
meeting,
we
decided
that
this
rfc
can
go
in
as
long
as
it
clearly
defines
what
functionality
pack
would
provide
to
ease
the
attachment
of
such
as
pumps
and
the
other
concern
that
a
lot
of
people
had
is
how
this
affects
our
general
doctor
files,
rfc,
which
is
another
important
feature
which
allows
for
arbitrary
image
extensions,
including
installing
arbitrary,
like
app
packages
or
yum
packages,
or
whatever
system
packages
basically,
and
how
this
rfc
would
play
in
when
you're
trying
to
create
s-pumps.
For
this
dynamically
extended
images.
A
I
think
we
decided
to
put
this
in
as
it
is
with
the
pack
functionality,
or
at
least
no
one
had
any
oppositions
to
that
in
the
last
working
group
meeting
and
we
are
still
waiting
for
votes.
But
anthony
was
supposed
to
update
the
run
images
from
rfc
with
the
pack
utility
commands
and
once
that's
there.
We
were
willing
to
like
let
that
go
for
now
to
provide
the
completed
functionality
across
the
output
image
and
then
figure
out
what
to
do
how
to
deal
with
the
dockerfiles
one.
Next.
A
Okay,
the
other
one
is
replace
positional
arguments
with
environment
variables.
I
think
the
idea
here
is
that
the
build
binary
currently
gets
these
three
variables
as
positional
arguments.
We
want
to
move
that
to
environment
variables
so
that
it's
easier
for
certain
build
backs
to
like
read
these
values
and
it's
easier
for
us
as
a
project
to
introduce
new
things
here,
which
is
backwards
compatible
because
of
the
way
positional
arguments
are
provided.
A
We
can't
introduce
or
add
new
things
here
without
breaking
the
build
binary,
so
as
we've
added
more
things,
we've
added
more
things
to
environment
variables,
as
opposed
to
this,
as
opposed
to
command
line
arguments.
So
I
think
this
is
just
to
make
it
consistent
with
the
rest
of
the
arguments
we
provide
the
build
binary.
A
But
that
was
it
on
this
rc.
There
are
a
few
others
that
I
still
have
as
drafts,
which
I
opened
up
now
yesterday,
which
are
not
yet
tagged,
but
they
think
maybe
some
of
the
people
here
would
be
interested
in
it.
One
is
this
image
history,
metadata
rfc,
which
sort
of
makes
it
easy
for
buildback,
created
images
to
be
visualized
by
tools
like
dive
or
on
docker
hub
or
like
other
container
registries
that
try
to
list
out
the
history
key
in
the
image,
config
and
pretty
print
it
out.
A
A
I
don't
think
there
are
any
breaking
changes,
apart
from
this
specific
edition
of
adding
a
name
key
to
the
slice,
so,
if
you're
using
app
slices,
currently,
you
can
just
specify
the
path
clubs.
This
proposes
that
we
add
a
name
key
as
well
to
uniquely
identify
the
application
slice
and
what
it
contains.
C
So
would
that
would
that
potentially
be
a
way
to
actually
have
a
timestamp
of
when
the
image
was
created?
It's
like
I.
I
understand
why
we
squash
those,
but
it's
always
like
the
biggest
first
question
I
get
from
new
people
and
one
of
the
biggest
complaints
is.
I
can't
see
when
my
image
was
created
so.
A
A
I
am
not
I've
currently
not
added
that
here.
I.
What,
like
any
comments,
appreciate
if
you
think
that's
useful
in
favor
of
reproducibility,
we
can
add
that.
C
C
Yeah
that
doesn't
sound
right,
okay,
never
mind,
then
that's.
A
A
Think
the
if
this
image
history
metadata
comes
in
I'm
guessing
like
we,
we
have
a
new
key
here
that
we'll
probably
have
to
add
the
other
one
that,
although
does
not
relate
directly
to
lip
cnb
but
will
fall
into
a
purview,
is
the
whole
utilities
buildback
stuff.
So
I
think
when
we
were
doing
release
planning.
A
This
week
we
were
planning
out
the
buildback
api
08
and
currently
that
has
these
few
rfcs
and
which
is
like
remove
all
shell,
specific
logic,
so
removing
profile
d
scripts
and
the
dependency
on
a
shell
like
bash
on
the
life
cycle.
A
A
A
A
So
we've
noticed
that
there
are
like
some
common
requirements
that
the
bayes
implementation
should
provide,
which
which
should
allow
it
to
be
reused
in
the
way
that
the
cato
and
google
currently
do,
which
is
like
it's
a
it's
a
non-opinionated
api
binding
that
you
can
drop
now
utilities
to.
However,
you
want
so
that
goal
isn't
changing
in
terms
of
the
lip
cnb
core
functionality.
A
I
think
there
have
been
a
few
interface
changes
that
are
backwards
and
compatible
to
get
around
some
of
the
design
choices
we
made
as
part
of
lip
cnb
v1,
especially
the
idea
of
the
layer
contributor
and
replacing
that
with.
A
Replacing
that
with
something
that
allows
you
to
dynamically,
generate
labels,
bill
of
materials
and
other
things.
So
I
think
let
me
just
get
those
back
up,
although
they
are
merged
in
a
alpha
v2
branch-
that's
not
yet
being
released.
So
this
was
the
list
of
core
requirements
for
ellipse
and
bbv2.
This
does
not
include
the
utility
stuff
that
I'll
be
covering
later,
but
this
is
currently
the
functionality
that
lip
cnb
provides.
A
A
This
changes
it
to
a
normal
layer
object,
which
is
what
the
contributor
returned
in
the
first
place
and
using
that
to
create
the
output
layers.
There's
this
full
request.
That
adds
a
bit
more
detail
on
how
you
can
migrate
from
the
current
layer
contributor
to
this
new
format
and
why
this
new
format
is
more
powerful
than
what
the
layer
contributor
exposed.
A
This
is
still
in
version
2.0,
which
is
an
alpha
branch.
We've
not
yet
released
it,
but
we're
still
looking
for
feedback
on
whether
this
is
something
that's
useful.
Whether
there
are
restrictions
you
hit
because
of
the
layer,
contributor
concept
and
if
there
is
a
better
design
than
what
we
currently
have
in
our
alpha
branch.
That
you'd
like
to
propose.
C
A
couple
of
other
things
we
we
did
pull
out
the
old
bomb
entities
or
bomb
entries.
B
C
Was
deprecated
and
then
removed
and
we
added
all
the
new
source
bomb
stuff
and
then
there's
also
a
few
things
that
I
still
want
to
clean
up.
There's
some
logic
that
we
have
in
there
that's
handling
older
versions
of
the
build
pack
api.
I
think
we
can
probably
remove
that
too.
So,
we'll
just
support
the
the
latest
one.
Whatever
we
release
v2.
A
Are
there
like
I'm
just
curious
to
know
how
like
rob,
could
you
like,
we've
already
walked
through
like
how
packet
and
lip
back
want
to
use
lip
cnd,
but
I'd
be
curious
to
hear
your
opinion
on
how
google
plans
on
using
lip
syndrome
if
they
have
any
opinions
on
the
v2
design.
A
B
Hi,
can
you
hear
me
okay,
that
was
weird
it
just
wasn't.
It
wasn't.
Working
yeah,
I
was
gonna
say,
is,
I
think,
I'm
too
new
to
the
project.
I've
only
been
on
the
project
like
three
weeks,
I'm
too
new
an
opinion.
B
A
And
like
so,
we
know
that,
like
we,
you
currently
wraps
lip
cnb,
yes
and
like.
I
was
just
wondering
if
there's
anything
we
can
do
on
our
side
so,
like
I
know,
there's
a
bunch
of
things
across
various
like
these
utility
libraries
that
we've
implemented
in
common
so
like
like
handling
layer,
life
cycle,
profiling,
timing
file,
io
management
checks
and
calculations.
So
things
like
this,
I
know
that
we've
implemented
across
packet,
lip
pack
and
the
gcp
build
pack
library.
A
B
Or
yeah
I
mean,
I
think
the
list
you
have
makes
sense
and
we
would
probably
want
to
drop
our
stuff
in
lieu
of
that
if
made
available
so
but
yeah,
I'm
not,
I'm
not
super
familiar
yet
with
with
everything
and
don't
have
a
ton
of
opinion.
Yet.
A
Yeah,
I
mean
I'll,
add
a
link
to
this
document.
So
if
you
have
some
comments
or
something
you
can
leave
it
later,
asynchronously
I'll
also
add
a
link
to
all
the
requests
and
the
plan
changes
we
have
for
v2.
So
in
case
there's
anything
that's
like
that
is
making
things
harder
for
you
or
if
there
are
any
features
that
would
make
things
easier
for
you
please.
Let
us
know.
A
I
think
the
other
thing
I
wanted
to
ask
was
like
the
original
reason
we
got
in
touch
in
the
first
place
like,
and
we
are
also
trying
to
collect
feedback
on
the
s
bomb
feature.
I
don't
know
if
you've
had
a
chance
to
look
at
what,
like
the
implementation
or
like
how
you
would
implement
it
in
google
buildbacks,
and
if
you
have
any
feedback
on
how
the
bad
team
could
provide
better
utilities
to
generate
those
as
forms
in
the
first
place.
B
Yeah,
so
google,
you
know,
wants
to
support
software
build
materials
with
with
all
builds.
Google
is
still
trying
to
figure
out
how
they
want
to
do
that.
Do
they
want
to
do
like
you
know,
container
scan
of
the
file
system,
or
do
we
want
to
you
know,
take
what
the
language
toolkit
gives
us
you
know
maven,
will
you
know
maven
dependency
plugin
prints
out
whatever
plug
that
in
there?
B
Maybe
a
combination
of
the
two,
I'm
not
sure
I
haven't
looked
too
much
at
what's
available
with
buildpacks,
but
my
impression
is
it's
just
kind
of
like
a
very
like
skeleton
format
like
it's
like
a
kind
of
a
layout
potentially
but
not
much
beyond.
That
is
that
right,
yeah.
A
A
Is
there
anything
else
we
want
to
talk
about
lipsy
and
baby?
Do
I
know
that
in
the
last
packy
meeting
frankie
had
some
questions
about?
We
do
that
she
was
going
to
regroup
with
the
other
utility
maintainers
about.
I
don't
know
if
there
was
any
update
on
that
or
if
forest
has
any
updates
on
like
the
packet
experimental
version
that
uses
lipscan
bb2.
C
A
A
Yeah
ryan:
do
you
have
any
points
down
on
me
too?
I
know
you've
contributed
a
bunch
of
things.
D
I
think
there's
maybe
in
my
mind,
just
some
like
open
questions
about
some
of
the
there's
like
some
printing
functions,
like
almost
every
type
provides
some
sort
of
print
function
off
of
it.
I
think
it's
for
like
debugging
purposes,
I
guess
my
question
was
like
is
necessary
in
the
api.
Are
people
using
those
are
those
load-bearing
apis
slower?
Would
people
you
know?
Would
people
be
upset
if
they
disappeared.
D
I
think
I
was
just
looking
at
the
like
the
golang
package
documentation.
I
think
it's
like
pretty
obvious
from
that
point
when
you
just
kind
of
like
scan
through
the
index
of
the
docs.
D
Yeah,
so
there's
a
bunch
of
them
that
just
have
string
functions,
hung
off
them,
so
bindings
have
a
string
application
path.
Formatter
has
a
string
and
I
don't
think
in
any
case,
they're
like
any
sort
of
like
structured
output.
So
it's
not
like
machine
parcel
or
anything
they're
like
human,
readable
strings.
So.
A
D
A
I
think
all
these
stringer
interfaces
are
for
like
when
we
fail
to
parse
bindings
or
something,
and
we
like
output,
debug
logs,
saying
that
hey
this
is
this
the
list
of
bindings
we
found
or
we
or
something
went
wrong.
So
I
think
we
just
mainly
use
it
for
debugging
in
our
logs,
like
where
we
just
pass
the
object
and
it
prints
out
the
string.
A
Yeah,
I
think
that
might
daniel
you
do
you
remember
if
we
use
string
anywhere.
C
What's
the
what's
the.
A
C
D
All
right,
that's
fair,
I
think
the
other
ones
I
saw
were
just
like.
They
appeared
to
be
some
sort
of
like
thing
you
could
call
if
you
wanted
to
output
some
debug
thing
in
some
sort
of
participle
format,
and
I
kind
of
just
was
wondering
like
I
did.
I
couldn't
figure
out
if
they
were
like
actually
used
internally
in
the
code
in
any
way
or
if
they
were
like
meant
entirely
as
like
external
facing
apis
for
folks
to.
A
A
D
A
A
D
A
C
I
I
mean
I,
I
use
the
debug
output
reasonably
often,
but
I
don't
really
care
too
much
how
that
gets
written.
If
it's,
if
it's
using
this
and
is
necessary,
then
then
I
would
say
it's
important,
but
if
it's
there's
other
ways
to
write
the
same
debug
output,
I
wouldn't
be
opposed
to
removing
it.
D
All
right,
I'm
just
trying
to
understand
for
me
like
if
I
was
interacting
with
these
types,
I
would
just
like
use
a
format
string
and
pull
the
fields.
I
wanted
to
actually
get
information
from
like
more
manually,
just
kind
of
how
I
think
about
doing
this
type
of
thing
versus
relying
on
you
know
something.
That's
come
from
a
library
or
redefining
the
stringer
interface.
D
Unless
I
was
like
strictly
required
of
some
like
library,
I
was
passing
this
thing
into,
but
it
sounds
like
there's
at
least
some
plausible
concern
about
this
as
a
useful
utility.
So
I'm
not
going
to
propose.
We
do
anything
with
it.
A
D
The
only
other
thing
I
would
say
is
that
paquetto
teams
been
working
on
a
alternative.
S-Bomb
implementation
got
like
an
open
pr
that
we've
been
having
a
conversation
around.
D
Our
idea
generally
has
been
to
leverage
sift
like
the
scanning
tool
to
generate
s-bombs.
I
can
drop
the
pr
we
have
open
in
the
chat
here,
but
what
we
have
landed
on
as
an
api
is
not
really
what's
shown
in
the
top,
but
more
shown
later
in
comments
towards
the
bottom.
D
The
major
I
think,
the
major
difference
between
what's
available
in
lip
c
and
b,
and
what
is
proposed
here,
is
we're
providing
like
a
little
bit
more
first
class
support
for
basically
handing
the
api
back,
what
the
s-bombs
end
up
being
so
we
ask
for
like,
instead
of
just
saying,
like
here's,
where
an
s-bomb
could
be
possibly
written,
do
what
you
will
and
write
one
there.
We
do
a
little
bit
more
of
the
like
handling
of
that.
D
So
we
just
ask
for
like
an
s-bomb
pairing,
where
we
basically
say
like
give
us
an
extension
and
a
reader
and
we'll
handle,
like
writing
it
to
the
proper
locations
on
the
file
system.
For
you
interesting
and
then
that's
in
addition
to
there's
like
a
another
library,
we're
introducing
that
actually
does
all
of
this
sift
stuff
so
like
using
sift
to
generate
your
s-bombs.
That
part
is
like
in
a
separate
package.
That's
entirely
optional,
but
the
top-level
packet
api
now
includes
this
kind
of
like
file
extension
reader
mapping.
D
A
I
think
the
reason
we
went
for
just
providing
the
file
path
is
that
people
can
sometimes
call
binaries
to
generate
the
s
forms
as
opposed
to
a
library,
and
these
binaries
typically
take
the
output
path.
So,
like
a
variable
or
command
line
flag,
I
mean-
and
we
I
guess
we
didn't
want
users
to
like
capture
the
standard
out
from
these
tools
into
a
reader
interface
and
then
give
it
back
to
us
and
if
they
wanted,
they
could
implement
an
interface
on
top
of
lip
cnb.
That
does
implement
that
reader
writer
interface.
A
That
you'd,
like
with
what
we
currently
provide.
So
I
think
that's
why
we
left
it
at
just
providing
the
paths
as
opposed
to
writing
it
out
on
disk.
D
That's
fair,
I'm
not
suggesting
that
lib
pack
or
lib
cnb
change
just
that,
just
bringing
it
up
as
an
alternative
implementation
that
folks
might
get
some
ideas
from.
A
Would
you
is
there
anything
that
in
lip
cnb
that
would
stop
you
from
writing
this
sort
of
an
interface
from
what
we
already
provide
like?
If
we
give
you
the
file
path,
can
you
wrap
it
up
in
this
interface
that
you
have
so
that
it
you,
the
packet,
provides
an
interface
to
take
in
a
reader,
and
it
writes
it
out
to
that
box.
D
I
mean,
I
think
there
is,
to
a
certain
extent
right.
We'd
have
to
do
things
that
I
don't
think
are
the
right
ways
to
go
about
doing
them
like
we'd
have
to
wrap
the
lip
cnb
layer
in
a
thing
that
is
capable
of
taking
this
alternative
api,
because,
like
the
way
we're
delegating
the
right
is
like
through
the
type
itself.
D
The
way
the
way
packets
layer
stuff
is
structured
is,
like
you
basically
hand
back
a
like
a
go
type
object
that
has
all
of
the
metadata
about
the
layer,
and
then
packet
is
the
one
responsible
for,
like
writing
that
stuff
out
in
the
right
formats
that
comply
with
the
spec,
and
that
is
kind
of
broken.
If
half
the
metadata
gets
written
by
the
library,
but
this,
like
other
piece
of
metadata,
is
written
by
a
build
pack
itself.
Yeah.
D
And
we
don't
but
like
given
the
experience
on
this,
we
maybe
want
to
think
about
providing
some
more
first
class
apis
for
that.
As
far
as
like
thinking
about
having
a
file
written
somewhere,
there's
no
reason
we
couldn't
change
the
api
to
be
like
a
read,
closer
api,
in
which
case,
if
you
have
something
written
to
a
file,
you
just
immediately
turn
around
and
open
the
file
and
pass
the
you
know,
file
descriptor
directly
to
the
api
say:
here's
where
this
thing
is.
D
A
I
think
it's
also
a
tough
situation
for
us
because,
like
the
so
for
profile,
the
ellip
cnb,
I
think
currently
does
allow
you
to
just
pass
a
string
and
we'll
write
it
for
you.
I
don't
I
mean
I'll
confirm
that,
but
for
the
main
issue
we
have
is
with
exec,
which
is
like
we
just
provide
a
path
where
your
exec
binary
can
be,
and
you
have
to
put
it
there.
A
A
We
don't
define
what's
in
the
files,
so
lib
cnb
typically
has
written
files
where
the
project
owns
the
specification
like
in
terms
of
what
goes
in
the
contents
of
those
files
and
like
we
just
provide
file
parts
for
things
that
are
outside
of
a
specification,
but
you
may
generate
in
different
ways
if
that
makes
sense,.
D
Yeah
I
mean,
I
think,
we're
doing
the
same
right.
We're
really
all
we're
asking
for
is
like
the
file
extension
bit
and
we're
doing
the
part
that
the
spec
does
specify,
which
is
like
the
file
has
to
start
with
the
prefix
layer,
name,
dot,
s-bom
dot,
and
then
you
give
us
the
file
extension
and
then
the
contents
again
is
just
like
it's
a
reader.
You
can
put
whatever
you
want
in
there.
D
Yeah,
I
think
the
reason
we
maybe
haven't
done
very
much
on
the
profile
decide
is
we
don't?
I
think
we
have
one
build
pack,
that
is
a
non-java
build
pack
that
leverages
profile
d
or
maybe
two,
so
we
just
don't
have
a
ton
of
need
for
there
to
be
like
a
nice
api
around
the
profile
d
stuff.
A
I
think
we
are
also
nearing
the
end
of
our
meeting.
Is
there
anything
else
we
want
to
talk
about
on
v2.