►
From YouTube: CNB Weekly Working Group: 2021-11-18
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).
B
I
guess
I
had
a
question
about
releasing
the
spec.
I
know
we
had
trimmed
the
buildpak
07
and
platform
08
apis.
B
A
Yeah
I'll
take
a
look
at
that
today.
I
think
terence
had
taken
it
over
from
emily
and
terence
is
out
right
now,
so
I
had
told
him
that
I
would
take
care
of
it.
So
at
least
the
release
part
is
on
me
and
I
can.
I
need
to
probably
need
to
approve
prs
or
something
too,
and
we
can
we
can
do
it
without
terrence's
approval.
B
Okay,
awesome:
if,
like
the
release,
notes
or
anything,
I
can,
I
can
provide
some
stuff.
C
A
B
D
On
the
lib
cnb
side,
thanks
to
daniel
we've,
got
the
library
up
to
date
with
the
paco7.
I
think
this
is
the
first
time
we'll
be
trying
to
cut
an
alpha
release
rather
than
like
a
stable
release,
since
the
ap
isn't
out
yet,
but
the
picado
folks
want
to
use
it
in
the
downstream
libraries.
D
It's
mainly
alpha
because,
like
the
api
might
change
before
it's
punched,
the
spec,
so
we
don't
want
to
come
into
anything
that
would
be
backwards
and
compatible,
but
that's
pretty
much
it
I'll
be
trying
to
make
a
alpha
release
today.
Hopefully,
after
this
meeting.
A
Cool
all
right:
are
we
ready
to
move
on
to
discussing
the
rfcs
any
other
updates
before
that.
A
All
right,
first,
one
is
system,
build
packs.
This
is
mine
actually,
and
we
I
think,
we've
discussed
this
in
the
past,
but
now
that
the
official
build
packs
rc.
A
A
The
proposal
uses
a
new
system
table
and
builder
tunnel,
where
you
can
define
pre
and
post
build
packs
very
similar
to
the
pre
and
post
that
you
can
use
in
your
buildback
groups
in
in
project
tamil
and
essentially
working
the
same
way,
which
is
why
they're
outside
of
the
order.
So
they
don't
need
to
be
explicitly
added
to
every
group.
A
A
B
A
So
so,
like
a
really
concrete
example,
the
the
shell
specific
logic
it's
removed
from
the
life
cycle,
and
so
that
behavior
is
gone
and
then
the
heroku
builder,
because
the
heroku,
the
owners
of
the
roku
builder,
want
to
keep
that
that,
like
dot
profile,
behavior
and
things
like
that
would
add
a
system
pre
build
pack
that
replicates
that
that
bash
behavior,
that
shell
behavior,
so
that
doesn't
that
means
that
not
every
build
pack
or
every
builder
would
have
that
right
and-
and
I
think
that
makes
sense,
because
if
you
are
building
images
from
scratch
or
where
you
don't
want
to
have
shell,
you
know
a
shell
as
part
of
the
build
or
as
part
of
the
the
launch
image,
then
that's
the
whole
reason
for
removing
it
from
life
cycle
or
part
of
the
reason
for
removing
the
life
cycle.
A
Yeah
because
we
would
yeah
the
main
reason
is
that
we
want
it
to
be
added,
even
if
there's
a
custom
group
so
like
if
someone
provides
dash
b
on
the
pax
cli
command-
or
you
know,
in
a
project
tamil,
essentially
like
the
goal
in
doing
this
and
having
the
system
build
pack
is
to
make
it
less
of
a
normal,
build
pack
and
more
of
a
just,
a
behavior,
that's
a
part
of
that
builder,
or
that
you
know
that
build
so
to
speak.
A
So,
even
if
you
and
you
can
imagine
in
the
heroku
case
where
like
where
we're
really
focusing
on
like
the
developer
experience-
and
we
want
users
to
not
have
to
think
about
things
like,
oh,
how
do
I
get
my
dot
profile
to
run,
even
if
they're
specifying
custom
build
packs?
We
want
that
to
be
something
they
don't
have
to
think
about.
C
Okay
and
looking
at
the
rfc
there's
no
way
to
actually
like
configure
this
or
or
mutate
this
right,
it's
the
idea
behind
it
is,
you
could
keep
all
of
them,
enabled
or
disable
all
of
them.
There's
no
in
between.
A
Correct
yeah
I
did
throw
in
a
disable
system,
build
packs.
I
don't
think
it's
necessary
to
like
tweak
one
or
one
or
some
of
them
on
and
off
like.
If
people
have
opinions
about
the
like,
let's
say:
there's
three
system
build
packs
and
they
only
want
one
of
them.
It's
very
easy
to
disable
all
of
them
and
then,
as
you
were
saying
manually,
include
the
one
you
want
in
your
custom,
build
pack
group,
so
it
can
be
done
and
I
think
this
needing
to
tweak
them
is
already
sort
of
an
advanced
capability.
A
Yeah
there
is,
they
are
not
special
in
their
execution,
depending
on
how
where
we
settle
on
the
build
plan
stuff,
I
think
I
think
most
of
us,
I
think
I
also
am
leaning
towards
just
build
plan
works
like
normal,
but
I
could
also
see
reasons
for
just
totally
disabling
build
plan,
but
otherwise
yeah.
A
A
A
C
I
would
also
say
that
it's
probably
not
worth
limiting,
which
ones
are
there.
I
think,
then
they
become
something
different
right.
Then
they
are
really
system,
build
packs
that
aren't
build
packs
like
standard
build
packs,
they're,
not
order
build
packs
and
and
so
forth,
and
I
guess,
with
that
same
mentality,
I
would
say
that
that
statement
about
whether
or
not
they
have
they
influenced
the
build
plan
kind
of
affects
that.
A
A
I
think
that's
all
the
more
reason
for
build
plan
just
to
work
the
same
way,
yeah
also
maybe
I'll
think
through
what
the
implications
of
that
might
be,
because
I
had
I
really
hadn't
so.
A
A
Yep
well
so
yeah
give
this
a
look.
If
you
have
some
time-
and
I
think
it's
gonna
be
a
little
while
before
we
finalize
it
with
the
holidays
and
stuff.
So
it's
not
super
urgent,
but
I
definitely
I
just
as
a
reminder.
I
would
like
to
get
this
finalized
before
we
ship
the
removal
of
shell,
specific
logic,
so
that
we
can
so
the
roku
builder
at
least,
can
have
a
bash
build
pack
of
some
kind.
A
No,
no,
I
I
yeah,
I
don't
think
that's
been
implemented,
but
that's
the
only
thing
that's
holding
that
back
was
like
the
pac
tommel
and
some
of
the
discussion
around
project.
Descriptor
changes
yeah.
So
I
think
that's
really
on
me,
but
we
we
finalized
that
right
before
we
did
the
big
schema
change
and
not
now.
I
think
that
that's
sort
of
put
to
bed.
A
I
should
probably
go
back
and
implement
that
rfc,
but
I
don't
think
there's
anything
about
that
that
conflicts
with
this,
because
after
you
process
the
pre
and
post
for
from
like
a
build
pack
from
from
a
package
toml,
the
end
result
is
just
a
normal
group.
So
we
may
need
to
specify
that
like
system
build,
packs
come
after
that,
but
it
would
work
exactly
the
same
way
because
it's
still
just
a
group
at
the
end
of
the
day.
B
I
think
that
makes
sense.
I
do
worry
that
it's
a
lot
of
for
someone
who's
not
familiar
with
as
familiar
with
our
project.
It
could
be
confusing.
I
know
that
I
feel
like
that
could
be
mitigated,
but
I
just
want
to
call
that
out
as
a.
A
No,
it's
totally
that's
totally
fair
and
I
think
that's
a
part
of
why,
with
the
system
build
packs,
I
want
it
to
be
a
very
transparent
thing
and,
like
I
even
proposed,
I
think
in
the
rfc
it
says
that
they
wouldn't
be
shown
like
when
you
run
a
build
and
it
shows
the
build
packs
that
are
detected,
that
it
wouldn't
actually
show
system
build
packs
so
that,
as
a
user
for
the
most
part,
you
don't
need
to
think
about
them,
because
they're
they're,
provided
by
the
builder
you
don't
have
control
over
them.
They're.
A
Essentially
like
a
behavior.
That's
specific
to
that
builder,
I
think
that's
probably
a
little
bit
contentious,
because
I
know
some
folks
want
the
want
them
to
show
up,
just
like
any
other
build
pack
would
in
a
group,
but
that
also
could
sort
of
force
you
to
have
to
think
about
the
things
that
you
were
talking
about.
Natalie.
A
Cool
all
right,
I
think
we
can
move
on
to
the
next
one,
which
is
s
bomb.
E
Yep
sure
I'll
I'll
prepare
this
can
y'all
see
this
cool.
So
you
know
I
see
a
couple
others
on
the
call
who
weren't
here
before
so
just
just
a
brief
overview.
The
objective
of
this
rc
is
to
give
a
more
complete
s-bomb
to
the
application
image
right.
We
had
the
previous
s-bomb
rc
for
basically
packages
that
the
bill
packs
would
provide
right,
but
to
get
the
full
picture
of
the
application
image
for
scanning
tools.
E
You
know
down
the
chain,
it'd
be
nice
to
have
something
for
the
stack
as
well
right,
so
presumably
stack
office
could
put
a
bomb
in
a
certain
location
and
then
we
could
append
the
digest
or
the
diff
id
somewhere
on
on
as
a
label-
and
you
know
maybe
downloading
but
merging-
was
cut
out
of
scope
for
this
rfc
right.
For
most
part,
we
just
want
it
there.
E
C
E
It
is
yeah,
and
you
know
steven
explicitly
said
that
you
know
doing
cosign
not
just
for
this,
but
for
bill
pack.
S-Bombs
too,
is
you,
know,
sort
of
deserves
its
own,
separate,
rfc
and
thought
process
and
discussion
right
like
this.
This.
If
we
were
to
do
that
right,
like
you
know,
basically,
we
just
have
to
draft
up
a
whole
nother,
rc
and
then
think
about
it
separately
right.
That
was
his
opinion.
C
It
is
strange
that
right
now,
the
way
that
s-bomb
for
build
packs
or
for
the
application
is
going.
Those
are
all
kind
of
baked
into
the
image.
D
They
they
don't
know
it
will
end
up
in
the
app
image.
Like
I
mean,
if
you
just
consider
buildback
api,
they
just
put
the
bomb
in
a
specific
place
and
it
will
be
restored
in
that
place
on
rebuilds
there's
like
even
if
we
do
move
to
move
the
bombs
to
a
separate
image
like
it
wouldn't
change
the
buildback
api,
it
will
change
the
platform
api,
it
wouldn't
change
the
buildback
api.
D
So
the
the
other
thing
is,
we
have
full
control
over
the
buildback
api
and
how
they're
executed
and
where
and
how
the
layers
are
created,
and
not
so
much
for
the
wrong
image,
at
least
for
the
application
layers.
We
can
guarantee
certain
things
about
who
modified
them
or
we
can
like.
The
life
cycle
can
put
defy
these
and
other
things
to
identify
other
layers
to
ensure
that
the
content
is
actually
not
tampered
with.
In
this
case,
it's
a
bit
weird
like
unless
we
create
some
more
tooling
to
actually
modify
the
base
image.
D
Have
it
work
eventually
with
rebase
and
have
it
work
with
eventually
with
like
the
whole
merged
thing
we
wanted
to
do
so.
D
E
So
I'm
just
sorry,
I
I
guess
I'm
just
not
fully
clear
on
that
last
statement.
Yes,
the
bill
pack.
Api
doesn't
change,
but
the
bonds
would
still
be
written
in
the
application
image
by
lifecycle.
I
mean:
do
we
want
those?
Would
we
want,
for
parody
sake,
to
move
it
to
like
a
you
know,
sidecar
image
is
that.
D
E
Okay,
all
right,
I
guess
I
wish
stephen
was
here
for
this,
but
it
looks
like
long
term.
We
all
know
what
we
want
right
long
term.
We
want
a
cosine
s
solution
where
the
bombs
are
in
a
separate
artifact
right.
But
what
do
we
want
in
short
term?
Right?
Let's
just
say
you
know
we
do.
We
did
just
do
this
whole
s,
bond,
track
of
work
for
the
bill,
packs
and-
and
we
just
accomplished
the
rfc
as
it
was
written
right
like
do.
D
D
What
bothers
me
is
how
this
would
impact
the
dockerfiles
rfc,
which
I
mean
we
we're
all
considering
that
to
be
in
fcp
but
like
this
is
introducing
a
new
format
that
the
other
one
can
potentially.
D
Not
easily
follow,
especially
because,
like
it
won't
have
like
we,
we
don't
have
a
solution
yet
for
generating
these
as
forms
for
the
run
image
on
the
other
rfc.
So
like
these
rfc
are.
These
rfcs
are
currently
in
motion,
and
I
don't
want
to
put
I'm
not
particularly
keen
on
introducing
things
that
we'll
have
to
change
almost
immediately.
D
D
That's
for
build
yes
for
runtime;
I'm
definitely
not
keen
on
introducing
a
binary
just
for
generating
s4
in
the
output
image
that
should
not
be
in
the
output
image,
like
the
a
binary
for
generating
like
inspecting
your
file
system,
those
and
generating
ns
form
that
should
not
end
up
in
the
output
application
image.
That
goes
against
like
ideal
of
creating
minimal,
secure
images
that
don't
contain
anything.
That's
not
necessary.
E
E
E
D
E
I
just
okay,
I
think
that's
a
slippery
slope
right.
It's
just
again
right!
You
think
about
the
world
we're
coming
from
we're,
trying
to
remove
stacks,
we're
trying
to
remove
mixes,
we're
trying
to
remove
the
tooling
and
the
abstractions
around
these
things
right
like
and
then,
if
you're
saying
hey,
we
need
to
do
more
than
a
dockerfile
right
to
make
the
run
image.
Do
more
do
up
it.
You
know
it
might
feel
like
it's
another,
confusing
thing
again
right
which
we're
trying
to
get
away
from
that.
That's
my
that's!
My
only.
D
Premature
thought,
I
think,
you're
on
the
same
page
there,
I'm
just
saying
that
the
other
rfc
currently
doesn't
have
a
way
of
doing
such
thing.
This
this
rfc
as
it
is,
is
completely
fine.
I'm
just
saying
that
it
seems
like
it'll,
be
very
short-term
because,
like
as
soon
as
we
introduce
the
docker
files
out
of
c,
we
won't
have
an
equivalent,
which
we
will
have
for
this
rfc,
I'm
assuming
the
tooling
that
we
create
for
this.
D
Rfc
is
just
like
back
and
then
euron
pack
attaches
form
on
an
existing
image
and
it
creates
a
new
one
with
the
spawn
attached
in
the
right
place.
I'm
just
saying
that
would
be
very
hard
in
the
dynamic
run
image
part,
because
one
you'll
need
to
generate
the
test
form
and
two
you'll
need
to
attach
it
in
some
way
and
all
of
the
stalling
has
to
somehow
work.
D
C
So
I
think,
anthony
if
I'm
understanding
correctly,
the
the
part
of
contention
is
imagine
you
had
docker
files
and
you
had
this
idea
of
trying
to
bake
in
the
s-bomb
right.
How
do
you
execute
arbitrary
stuff
on
the
run
image
and
ensure
that
the
s-bomb
gets
generated
properly,
while
not
baking
in
any
of
the
tooling,
into
the
run
image
or
the
final
app
image?
C
I
should
say
you
could
still
put
it
in
the
run
image,
but
it
should
not
be
out
in
the
app
image
and
typically,
I
think
the
solution
that
you
know
why
that
has
been
proposed
is
for
the
rebase
functionality
right
so
think
about
being
able
to
do
rebase
with
docker
files
in
a
baked
in
s-bomb,
and
if
you
could
solve
that
without
tooling,
in
the
final
app
image.
I
think
that
would
be
the
solution.
E
I
I
think
I
get
it
I
you
know,
I
think
we
at
least
I
I
think
I
understood
from
last
conversation
right,
there's
two
ways:
either,
there's
a
tool
inside
the
image
or
outside
you
know
outside
would
be
dramatically
slow
and
painful.
I
would
assume
right,
you
know.
D
D
I
think
yeah,
that's
less
so,
in
the
once,
we
have
the
support,
dockerfile
rfc
so
and
since
that's
like
the
immediate
next
step,
we'll
be
taking,
and
that's
probably
going
to
be
leading
up
to
the
next
couple
of
platform
and
buildback
apks
just
means
we're
introducing
something
for
one
api
that
we'll
be
deprecating
or
having
to
figure
out.
Another
solution
for
in
just
the
next
gpa.
E
B
B
B
B
Maybe
it's
in
a
separate
layer
that
you
don't
include
in
the
final
image
and
then,
when
you
do
a
rebase
you
check
for
either
the
presence
of
be
populated
as
bomb
or
a
gen
packages
binary
in
in
you
choose
one
way
to
get
them.
D
The
other
issue
with
gen
packages
is
that
it
needs
to
be
standalone
for
something
like
this
layer
stripping
to
work.
It
cannot
have
any
other
dependencies,
otherwise
you'll
be
polluting
the
rom
image
with
potential
dependencies
for
that
gen
package.
Finally,
which
is
another
big
constraint
we
have
not
introduced
in
the
buildbacks
api
so
far,
the
only
thing
that
does
something
like
that
is
the
lifecycle
and
we
maintain
responsibility
for
it.
So
those
are
the
only
considerations
I
had.
I
sorry
I
need
to
drop
for
another
meeting
but
happy
to
continue
this
conversation
onslaught.
E
All
right,
I,
I
guess
the
the
big
thing
I
was
getting
from
this
was
that
we
need
to
flesh
things
out
more
in
the
support,
docker
files,
rsc,
which,
to
be
honest,
I'm
not
very
intimate
with
as
of
right
now,
but
even
if
we
were
to
implement
this
it'd
likely
have
to
change
or
be
modified
immediately
right,
which
is
a
lot
of
waste
of
engineering
effort.
B
B
Oh
sorry,
anthony.
I
just
had
one
comment.
I
know
this
was
sort
of
deeply
unsatisfying
conversation
but
like
if
there's
any
way
that
the
rfc
like
on
github,
because
I
feel
like
there's
so
much
context
that
was
talked
about
today
and
last
week
that
I'm
just
going
to
forget
after
this
meeting
like.
Is
there
any
way
to
like
track
down
all
the
points
that
were
raised
and
put
them
in
github
so
that
we
can
align.
E
Sure
I'll
try,
my
best,
I
was
going
to
say
next.
Steps
for
me
is
definitely
to
you
know.
Give
some
contact
to
steven
like,
like
I
said,
he's
been
the
other
big
voice
in
this.
Probably
more
than
me
so
and-
and
you
know
to
have
this
rc
hinge
on
another
rfc
is
is
sort
of.
E
I
don't
know
this
other
other
other
thing
to
deal
with.
So
yes,
next
steps
I'll
get
it
down
somewhere,
somehow,
preferably
after
a
conversation
with
stephen
about
the
points
raised
today.
A
Yeah
I
given
that-
and
I
I
think
terence's
vote
is
essentially
waiting
on
him
to
come
back
from
vacation.
I
think
you
can
assume
that
support
doctor
files
is
fairly
stable.
If
that
helps
you
and
potentially
done
just
waiting
a
formal
ratification
kind
of
thing.
E
I
think
I
I
think
it
is
right,
but
this
this
one
on
this
answer,
questions
about
you
know
what
this
gem
packages
interface
looks
like
and
what
it
does
and
how
it
you
know,
makes
its
way
into
the
final
image
right.
That's
I
I
don't
know
if
we
we've
clearly
hashed
it
out.
Yeah
I
think
sam
is,
is
asking
for
us
to
not
not
smooth
over
it
and
sort
of
hash
it
out.
C
Yeah,
what's
the
I
know,
this
might
be
a
little
bit
of
a
future
topic,
but
what
is
the
release?
Schedule
look
like
because,
from
my
perspective,
it
looks
like
support
docker
files.
That
would
be
an
fcp
right
now
that
would
go
in.
Is
that
really
a
thing
that
would
be
implemented
right
away?
I
know
s-bomb
has
a
little
bit
more
of
a
priority.
C
It
looks
like
right
now,
so
I
guess
if
sam
is
okay
with
the
s-bomb
related,
you
know
to
run
images
and
stuff
like
that,
and
then
we
more
or
less
you
know,
contemplate
and
simmer
on
the
support
for
docker
files
and
really
hash
that
out.
Could
we
still
roll
out
with
your
proposed
solution,
anthony
and
figure
out
the
docker
file
support
after
the
fact.
E
I
think
so
right,
I
think
the
thing
is,
nobody
wants
to
do
extra
work
right.
Nobody
wants
to
implement
this
and
then
have
to
rewrite
it,
because
it
didn't
work
out
for
support
doctor
files
right.
This
can
be
done
if
you're
talking
about
which
one
can
be
done.
First,
this
one
can
be
done
first
right,
it's
just
about.
I
guess,
making
a
mistake
right
and
having
to
redo
stuff.
C
Yeah
I
from
what
I
gathered,
everything
that
sam
said.
C
It's
really
like.
Yes,
there's
like
a
long-term
version,
and
you
know
that
that's
kind
of
maybe
something
to
think
about,
but
the
contention
is
more
or
less
the
gen
pack
and
how
to
solve
the
issue
when
docker
files
come
in
right.
But
if
we
say
okay
now
we
have
this
like
s-bomb
thing
right
and
we
need
to
be
able
to
regenerate
that
and
that's
actually
even
part
of
this
docker
files
rfc
right.
C
So
even
though
it's
an
fcp,
it
sounds
like
there's
more
contention
here
right
that
I
don't
think
it
should
be
merged
in
at
least
from
I
definitely
agree
with
sam.
I
don't
think
that
genpak
should
be
in
the
final
image,
so
the
support
our
docker
files
rfc,
should
have
a
mechanism
for
excluding
that
or
specify
a
mechanism
for
excluding
that
from
the
final
lamp
image
and
so
to
me,
that's
completely
separate
from
run
run
image
s
bombs,.
C
E
C
B
It
doesn't
make
it
a
little
more
complicated.
I
mean
I
don't
think
this
was
fully
thought
through
either
but
like
it
makes
it
more
complicated
for
a
platform
like
pac
to
say:
okay,
I'm
just
gonna,
take
the
docker
files,
apply
them
to
the
run
image
and
then
provide
that
to
the
exporter.
You
know
for
it
to
use,
consume
the
extended
run
image
right,
like
I
think
that
was
sort
of
assumed
that
that
workflow
would
be
possible.
B
And
you
know
that
it's
right,
like
that's
additional
logic,
that
the
platform
is
going
to
have
to
implement
and
now
we're
talking
about
additional
logic
that
the
platform
needs
for
finding
the
layer.
That
includes
the
s-bomb
or
I
don't
know
like
I'm
just
confusing
myself
right
now,
but
I'm
I
don't
know
if
there
was
like
some
hand
waviness
in
the
support,
docker
files
rfc
that
maybe
now
we're
running
into
yeah.
C
I
agree
with
that.
I
think
in
that
regard,
that
should
be
hashed
out
a
little
bit
more.
I
think
it's
really
close
to
getting
solved,
but
it's
just
a
little
bit
more
work.
E
I
appreciate
it.
I
appreciate
you
entertaining
helping
me
out
at
least
hashtag
the
conversation.
A
Yep,
so
the
next
one
is
pac
tommel.
This
is
a
rfc.
I
opened
this
week.
Definitely
take
a
look
at
it.
They'll
get
your
feedback.
A
Okay,
javier
aside
from
the
pact
humble
proposal
itself,
do
you
have
any
thoughts
and
valid
answer
might
be?
No
is
if
the
images
table
should
be
specific
to
pack
or
if
it's
or
if
it
should
be
general.
C
I
know
in
in
this
particular
case
the
idea
of
pac
tommo
it
from
a
user's
perspective.
It
might
get
a
little
bit
weird
if
you
upload
your
project
to
something
like
heroku
that
may
be
underneath
uses
pack
and
therefore
would
look
at
pactomel
for
configuration.
C
That's
a
little
bit.
You
know
again,
it
would
be
confusing
that
it
works
in
all
these
platforms
right,
but
it's
like
a
pack
specific
configuration
which
I
thought
only
worked
on
my
local
machine
right
and
then
you
go
to
something
like
kpac,
which
doesn't
use,
k
pack,
sorry
underneath,
then
it
wouldn't
work
there
right.
So
to
me
that
sort
of
difference
in
platform,
behavior
based
on
configuration
files,
is
still
a
little
bit
alerting
and
again,
my
position
is
more.
A
Yeah,
it
makes
sense,
I
actually
thought
of
it
in
one
direction
and
that,
like
the
heroku
example
where
or
any
platform
that
advertises
itself
as
a
distinct
platform,
but
is
actually
using
pack
under
the
hood,
if
it
opts
not
to
honor
something,
like
I
don't
think,
that's
jarring,
but
I
think
the
inverse
which
you
described
where
something
is
working
on
a
bun
like
on
circle,
ci
and
pack
heroku
and
then
all
of
a
sudden.
The
same
thing
doesn't
work
somewhere
else,
that's
surprising,
so
I
think
yeah.
A
I
feel
I
feel
like
it's
okay
for
a
platform
to
as
long
as
it's
not
masquerading
as
as
long
as
it's
not
advertising
itself
as
pac,
not
support
something
but
then
yeah
I
can
get.
I
don't
know.
We
have
a
whole
bunch
of
issues
like
this.
This
is
a
real
wrinkle,
because
I
was
thinking
the
back.
Specific
configuration
would
make
things
better,
but
it
might
make
things
worse.
C
C
Yeah,
I
think
spring
would
be
another
one
that
isn't
using
pack
but
works
very
particularly.
A
Man
going
through
this
images
table
thing
reminds
me
of
why
we
didn't
do
an
images
table
at
the
beginning,
there's
so
many
little
things
like
publishing
and
publishing
to
two
different
places
like
I
guess
that
can
just
be
like.
Essentially
one
is
a
true
publish
and
one
is
a
push
and
then
and
I'm
not
even
sure
how
that
works
like
do
you
have
to
pull
and
then
push
or
maybe
it
just
doesn't
work
with
publish.
A
I
don't
know
and
then
also
like
the
previous,
build
like
what,
if
one
has
it
and
one
doesn't,
do
you
just
ignore
it
completely
or
do
you
get
the
one
that's
available,
yeah.
D
D
C
Yeah
and
just
to
make
things
even
more
complex,
I
know
we're
running
out
of
time:
juan's
been
working
on
an
oci
layout
sort
of
functionality
for
the
life
cycle.
That
would
then
also
be
propagated
out
to
the
user,
most
likely
for
pac
and
you.
C
I
could
definitely
envision
users
wanting
like
a
mixed
match
of
stuff
where
they
want
to
use
a
previous
image
from
a
registry,
but
then
be
able
to
still
output
to
a
local
file
system
right
and
right
now
we
just
say
demon
or
daemon
and
or
registry
right.
We
don't
allow
them
to
mix
and
match
and
with
the
layout
local
file
system,
I
think
we're
gonna
want
to
mix
and
match
so
that
kind
of
exacerbates.
The
problem
that
you
just
mentioned.
A
Yeah
I'll
I'll
try
to
capture
some
of
this
in
the
images
table
rfc
and
make
sure
that
those
folks
are
aware
of
what
we're
talking
about.
C
Cool
yeah
and
you
could
point
them
to
the
recording
of
this.
You
should
have
a
url
yeah.