Re: Join the new Minimization Team

[Christian Glombek]

On Tue, Aug 27, 2019 at 3:27 PM John Harris  wrote:

> On Tuesday, August 27, 2019 6:18:41 AM MST Christian Glombek wrote:
> > Right now, one can do something like `dnf
> > --installroot=/mnt/new-buildah-root group install custom-environment`
> > to create a root for a container and installed group may include a
> package
> > manager or not.
>
> This would install `rpm` and `dnf` at the very least, and would most
> likely
> pull in many other supporting packages, unless something has changed since
> the
> last release, like checking against the string "buildah" or something like
> that.
>
>
That would really depend on the contents of that custom group, but you can
install a set of packages that way as well, as you would usually.
AIUI reducing the number of packages pulled in by dependency resolving is
another one of the aims of this effort for Fedora packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Tuesday, August 27, 2019 6:18:41 AM MST Christian Glombek wrote:
> Right now, one can do something like `dnf
> --installroot=/mnt/new-buildah-root group install custom-environment`
> to create a root for a container and installed group may include a package
> manager or not.

This would install `rpm` and `dnf` at the very least, and would most likely 
pull in many other supporting packages, unless something has changed since the 
last release, like checking against the string "buildah" or something like 
that.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Christian Glombek]

On Tue, Aug 27, 2019 at 2:09 PM Tristan Cacqueray 
wrote:

>
> On Tue, Aug 27, 2019 at 01:22 John Harris wrote:
> [snip]
> > No online updates is the exact issue I see with this. That's a security
> nightmare.
> >
> > If you don't have a package manager there, it simply will not be
> updated.
> > It'll be installed once, then either left there forever, un-updated,
> with tons
> > of vulnerabilities piling up.
> >
>

I see Kubernetes/OpenShift workloads as a very well suited use-case for
purpose-built, minimal containers that do not require a package manager.
There is a lot of tooling available right now to automate container builds,
continuous testing and integration, e.g ImageStreams on OpenShift.
In this model, changes to the container deployment are made by pushing a
new immutable image and executing a custom fitted update strategie:
staging, gradual updates, simultaneous versions, etc.
No container needs to be mutated ever. New ones are spun up, traffic is
rerouted, old ones are destroyed.

You have voiced your concern with this new proposed approach and it is
indeed not fitted for the workflow you are describing, but please let us
focus away from the status quo on to new ideas wrt the Minimization effort.
Also I assure you, nobody is planning to take the standard Fedora dnf
container away from you, or anybody.

IIUC the proposal from Christian to use rpm-ostree as a build stage to
> produce the runtime container, then you can still do online update, but
> instead of commiting the result of a dnf update, you commit a new
> rpm-ostree composed rootfs.
>
>
Yes, exactly. Although the container build tooling/system and the container
contents (i.e whether or not a package manager is included) are somewhat
orthogonal here:
Right now, one can do something like `dnf
--installroot=/mnt/new-buildah-root group install custom-environment`
to create a root for a container and installed group may include a package
manager or not.

I am not aware of a way to do the equivalent with rpm-ostree, yet, and
there are a lot of open questions I'd like to explore around that:
- How would a runtime update of the rpm-ostree-in-container work?
- Can we enable composing a dnf container with rpm-ostree (and the other
way around, use dnf to create an rpm-ostree container root)



-Christian







> Regards,
> -Tristan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Tristan Cacqueray]

On Tue, Aug 27, 2019 at 01:22 John Harris wrote:
[snip]
> No online updates is the exact issue I see with this. That's a security 
> nightmare.
>
> If you don't have a package manager there, it simply will not be updated. 
> It'll be installed once, then either left there forever, un-updated, with 
> tons 
> of vulnerabilities piling up.
>

IIUC the proposal from Christian to use rpm-ostree as a build stage to
produce the runtime container, then you can still do online update, but
instead of commiting the result of a dnf update, you commit a new
rpm-ostree composed rootfs.

Regards,
-Tristan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Monday, August 26, 2019 10:17:46 PM MST Samuel Sieb wrote:
> On 8/26/19 9:39 PM, John Harris wrote:
> 
> > I'm not saying not to use containers. There is a right way to do it, and
> > a
> > wrong way to do it. A container should be as the name describes, a
> > containerized installation of the distro in question, with the utilities
> > needed to support a given role. Not something that never gets updated,
> > never
 gets security fixes. Deploying new GNU/Linux based systems without
> > engaging a sysadmin or the sysadmin team sounds like a recipe for
> > disaster.
> 
> 
> That may be your use case, but not the way others use them.  You can 
> still use containers how you want.  But either do some research about 
> how containers can be used in different ways or stop telling others that 
> they're doing it wrong.  A common use case is for containers to be throw 
> away.  If something needs updating, a new container is created and 
> tested and then deployed replacing the existing one.  No online updates.
> 
> 
> > I disagree, and I find your remarks to be quite hostile. The smallest
> > viable
 container can exist without getting rid of required utilities,
> > such as the package manager.
> 
> 
> And you can still use it with the package manager if you want.  But 
> there are completely valid use cases that don't have any use for the 
> package manager and want the smallest container possible.  There was 
> nothing hostile about the replies to you.  They are just telling you 
> that your case is not the only one and to stop telling them that they 
> are wrong.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'm not telling anyone they can't do anything. However, it's a very bad idea, 
and if it gets done that way, it's a security issue. It's one thing if it's 
spawned as needed, then deleted in a few minutes or hours, and another if it's 
just left installed as-is. No online updates is the exact issue I see with 
this. That's a security nightmare.

If you don't have a package manager there, it simply will not be updated. 
It'll be installed once, then either left there forever, un-updated, with tons 
of vulnerabilities piling up.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Samuel Sieb]

On 8/26/19 9:39 PM, John Harris wrote:

I'm not saying not to use containers. There is a right way to do it, and a
wrong way to do it. A container should be as the name describes, a
containerized installation of the distro in question, with the utilities
needed to support a given role. Not something that never gets updated, never
gets security fixes. Deploying new GNU/Linux based systems without engaging a
sysadmin or the sysadmin team sounds like a recipe for disaster.


That may be your use case, but not the way others use them.  You can 
still use containers how you want.  But either do some research about 
how containers can be used in different ways or stop telling others that 
they're doing it wrong.  A common use case is for containers to be throw 
away.  If something needs updating, a new container is created and 
tested and then deployed replacing the existing one.  No online updates.



I disagree, and I find your remarks to be quite hostile. The smallest viable
container can exist without getting rid of required utilities, such as the
package manager.


And you can still use it with the package manager if you want.  But 
there are completely valid use cases that don't have any use for the 
package manager and want the smallest container possible.  There was 
nothing hostile about the replies to you.  They are just telling you 
that your case is not the only one and to stop telling them that they 
are wrong.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Monday, August 26, 2019 9:39:47 PM MST John Harris wrote:
> On Monday, August 26, 2019 9:16:30 PM MST Tomasz Torcz wrote:
> 
> > On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
> > 
> > 
> > > On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
> > > 
> > > 
> > > > 
> > > > Wow, a model like _distroless_ is exactly what I think we need in and
> > > > from
> > > > Fedora to enable making those minimal, purpose-built and
> > > > service-specific
> > > > containers.
> > > > 
> > > > I was thinking of a concept that has rpm-ostree compose a set of
> > > > packages
> > > > to a root dir, and put that in a container with Buildah.
> > > > Not sure how feasible it would be to add that functionality (as
> > > > opposed
> > > > to
> > > > simply using dnf for this), but I'm thinking it would be super neat
> > > > to
> > > > have a coreos-assembler that also does container composes from an
> > > > ostree manifest, in the same way it assembles OS images in different
> > > > formats for different platforms.
> > > > 
> > > > I'd also like to link to Adam's super informational page here:
> > > > https://asamalik.fedorapeople.org/container-randomness/report-f31.html
> > > > 
> > > > It would be great if we could include infos about the package sets of
> > > > our
> > > > ostree-based composes in there as well (FCOS, Silverblue and IoT).
> > > > Also
> > > > note that our container scratch build size has gone up dramatically
> > > > in
> > > > F31
> > > > (I don't know why, yet).
> > > > 
> > > > cc'ing Ben Breard and Sanja Bonic for their general interest in the
> > > > Minimization effort.
> > > 
> > > 
> > > 
> > > That sort of container is exactly the kind of thing that *cannot be 
> > > maintained*. I say this as a sysadmin in a fairly large environment,
> > > that
> > > 
> > > container simply *would not get updated*. It'd sit until it either quit
> > > 
> > > working or somebody noticed it and removed it because it was a security
> > > risk,  full of vulnerabilities.
> > 
> > 
> > 
> > 
> >   John, if you do not want to use the containers, then don't do it.
> > 
> > There are people who like containers and are serious about them.  Being
> > serious means that one has automated pipeline that builds, tests and
> > deploys updated container, without engaging sysadmins.
> > 
> > 
> >   Your remarks do not move discussion forward.  The point is how to get
> > 
> > smallest viable container.  Your comments ignore decades of experience
> > of containerising workloads.
> > 
> > -- 
> > Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
> > Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
> > o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> > Archives:
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.or
> > g
> 
> I'm not saying not to use containers. There is a right way to do it, and a 
> wrong way to do it. A container should be as the name describes, a
> containerized installation of the distro in question, with the utilities
> needed to support a given role. Not something that never gets updated,
> never gets security fixes. Deploying new GNU/Linux based systems without
> engaging a sysadmin or the sysadmin team sounds like a recipe for disaster.
> 
> I disagree, and I find your remarks to be quite hostile. The smallest viable
> 
 container can exist without getting rid of required utilities, such as
> the package manager.
> 
> -- 
> John M. Harris, Jr. 
> Splentity
> https://splentity.com/
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

For an example of containers used properly, please see my 2016 Fedora Magazine 
article on systemd-nspawn:
https://fedoramagazine.org/container-technologies-fedora-systemd-nspawn/

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Monday, August 26, 2019 9:16:30 PM MST Tomasz Torcz wrote:
> On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
> 
> > On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
> > 
> > > 
> > > Wow, a model like _distroless_ is exactly what I think we need in and
> > > from
> > > Fedora to enable making those minimal, purpose-built and
> > > service-specific
> > > containers.
> > > 
> > > I was thinking of a concept that has rpm-ostree compose a set of
> > > packages
> > > to a root dir, and put that in a container with Buildah.
> > > Not sure how feasible it would be to add that functionality (as opposed
> > > to
> > > simply using dnf for this), but I'm thinking it would be super neat to
> > > have a coreos-assembler that also does container composes from an
> > > ostree manifest, in the same way it assembles OS images in different
> > > formats for different platforms.
> > > 
> > > I'd also like to link to Adam's super informational page here:
> > > https://asamalik.fedorapeople.org/container-randomness/report-f31.html
> > > It would be great if we could include infos about the package sets of
> > > our
> > > ostree-based composes in there as well (FCOS, Silverblue and IoT). Also
> > > note that our container scratch build size has gone up dramatically in
> > > F31
> > > (I don't know why, yet).
> > > 
> > > cc'ing Ben Breard and Sanja Bonic for their general interest in the
> > > Minimization effort.
> > 
> > 
> > That sort of container is exactly the kind of thing that *cannot be 
> > maintained*. I say this as a sysadmin in a fairly large environment, that
> > 
> > container simply *would not get updated*. It'd sit until it either quit 
> > working or somebody noticed it and removed it because it was a security
> > risk,  full of vulnerabilities.
> 
> 
>   John, if you do not want to use the containers, then don't do it.
> There are people who like containers and are serious about them.  Being
> serious means that one has automated pipeline that builds, tests and
> deploys updated container, without engaging sysadmins.
> 
>   Your remarks do not move discussion forward.  The point is how to get
> smallest viable container.  Your comments ignore decades of experience
> of containerising workloads.
> 
> -- 
> Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
> Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
> o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'm not saying not to use containers. There is a right way to do it, and a 
wrong way to do it. A container should be as the name describes, a 
containerized installation of the distro in question, with the utilities 
needed to support a given role. Not something that never gets updated, never 
gets security fixes. Deploying new GNU/Linux based systems without engaging a 
sysadmin or the sysadmin team sounds like a recipe for disaster.

I disagree, and I find your remarks to be quite hostile. The smallest viable 
container can exist without getting rid of required utilities, such as the 
package manager.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Tomasz Torcz]

On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
> On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
> > 
> > Wow, a model like _distroless_ is exactly what I think we need in and from
> > Fedora to enable making those minimal, purpose-built and service-specific
> > containers.
> > 
> > I was thinking of a concept that has rpm-ostree compose a set of packages
> > to a root dir, and put that in a container with Buildah.
> > Not sure how feasible it would be to add that functionality (as opposed to
> > simply using dnf for this), but I'm thinking it would be super neat to have
> > a coreos-assembler that also does container composes from an ostree
> > manifest, in the same way it assembles OS images in different formats for
> > different platforms.
> > 
> > I'd also like to link to Adam's super informational page here:
> > https://asamalik.fedorapeople.org/container-randomness/report-f31.html
> > It would be great if we could include infos about the package sets of our
> > ostree-based composes in there as well (FCOS, Silverblue and IoT). Also
> > note that our container scratch build size has gone up dramatically in F31
> > (I don't know why, yet).
> > 
> > cc'ing Ben Breard and Sanja Bonic for their general interest in the
> > Minimization effort.
> 
> That sort of container is exactly the kind of thing that *cannot be 
> maintained*. I say this as a sysadmin in a fairly large environment, that 
> container simply *would not get updated*. It'd sit until it either quit 
> working or somebody noticed it and removed it because it was a security risk, 
> full of vulnerabilities.

  John, if you do not want to use the containers, then don't do it.
There are people who like containers and are serious about them.  Being
serious means that one has automated pipeline that builds, tests and
deploys updated container, without engaging sysadmins.

  Your remarks do not move discussion forward.  The point is how to get
smallest viable container.  Your comments ignore decades of experience
of containerising workloads.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
> On Wed, Aug 7, 2019 at 5:26 PM Colin Walters  wrote:
> > On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
> > > If you want small images, just use buildah.
> > 
> > Dockerfile-based multi-stage builds are significantly more popular than
> > this and should really be mentioned first.
> > 
> > I'm not saying `buildah` is bad, but...what you're talking about here also
> > encourages using the host as a build root which has various negatives.
> > 
> > And I think the main conversation to have is whether we should introduce
> > something more like
> > https://github.com/GoogleContainerTools/distroless
> > 
> > that basically just has:
> >  - glibc
> >  - ca-certificates
> 
> Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and
> 
> > that's it.
> > (While people often say both Rust and golang are statically linked, that's
> > true
> > 
> >  of the language code, but by default  Rust links to glibc, Go does not,
> > 
> > and I
> > 
> >  think what Rust does is better and should be encouraged, so we want a
> >  libc
> >  in this "ultramin" container)
> 
> Wow, a model like _distroless_ is exactly what I think we need in and from
> Fedora to enable making those minimal, purpose-built and service-specific
> containers.
> 
> I was thinking of a concept that has rpm-ostree compose a set of packages
> to a root dir, and put that in a container with Buildah.
> Not sure how feasible it would be to add that functionality (as opposed to
> simply using dnf for this), but I'm thinking it would be super neat to have
> a coreos-assembler that also does container composes from an ostree
> manifest, in the same way it assembles OS images in different formats for
> different platforms.
> 
> I'd also like to link to Adam's super informational page here:
> https://asamalik.fedorapeople.org/container-randomness/report-f31.html
> It would be great if we could include infos about the package sets of our
> ostree-based composes in there as well (FCOS, Silverblue and IoT). Also
> note that our container scratch build size has gone up dramatically in F31
> (I don't know why, yet).
> 
> cc'ing Ben Breard and Sanja Bonic for their general interest in the
> Minimization effort.

That sort of container is exactly the kind of thing that *cannot be 
maintained*. I say this as a sysadmin in a fairly large environment, that 
container simply *would not get updated*. It'd sit until it either quit 
working or somebody noticed it and removed it because it was a security risk, 
full of vulnerabilities.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Christian Glombek]

On Wed, Aug 7, 2019 at 5:26 PM Colin Walters  wrote:

>
>
> On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
> > If you want small images, just use buildah.
>
> Dockerfile-based multi-stage builds are significantly more popular than
> this and should really be mentioned first.
>
> I'm not saying `buildah` is bad, but...what you're talking about here also
> encourages using the host as a build root which has various negatives.
>
> And I think the main conversation to have is whether we should introduce
> something more like
> https://github.com/GoogleContainerTools/distroless
> that basically just has:
>
>  - glibc
>  - ca-certificates
>
>
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and
> that's it.
> (While people often say both Rust and golang are statically linked, that's
> true
>  of the language code, but by default  Rust links to glibc, Go does not,
> and I
>  think what Rust does is better and should be encouraged, so we want a libc
>  in this "ultramin" container)
>

Wow, a model like _distroless_ is exactly what I think we need in and from
Fedora to enable making those minimal, purpose-built and service-specific
containers.

I was thinking of a concept that has rpm-ostree compose a set of packages
to a root dir, and put that in a container with Buildah.
Not sure how feasible it would be to add that functionality (as opposed to
simply using dnf for this), but I'm thinking it would be super neat to have
a coreos-assembler that also does container composes from an ostree
manifest, in the same way it assembles OS images in different formats for
different platforms.

I'd also like to link to Adam's super informational page here:
https://asamalik.fedorapeople.org/container-randomness/report-f31.html
It would be great if we could include infos about the package sets of our
ostree-based composes in there as well (FCOS, Silverblue and IoT). Also
note that our container scratch build size has gone up dramatically in F31
(I don't know why, yet).

cc'ing Ben Breard and Sanja Bonic for their general interest in the
Minimization effort.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Wednesday, August 21, 2019 2:00:07 AM MST Tomasz Torcz wrote:
> On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
> 
> > Having a container without a package manager sounds like the worst
> > possible  thing to add to an already poorly implemented solution. In
> > reality, containers, regardless of what they're running, should be
> > treated as what they are, GNU/Linux installs. Each one should be self
> > sufficient from the host system, so that they can be properly updated
> > using a package manager. 
> > Each container should, realistically, be a self contained system.
> 
> 
>   You do not update the container. You rebuild it, creating new image
> with updated components, then you test out new image.
>   Package manager is only needed during the build (in fact, it
> is indispensable at this step) but not during runtime.
> 
> -- 
> Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
> Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
> o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Why in the world would anyone do such a thing? That is impossible to maintain, 
and is a horrible security risk.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Tristan Cacqueray]

On Wed, Aug 21, 2019 at 09:13 Colin Walters wrote:
> On Wed, Aug 21, 2019, at 7:34 AM, Daniel Walsh wrote:
>
>> I agree.  Entering a container and doing a yum update is an
>> Anti-pattern.
>
> This is a complex discussion - I think we need both.  Personally I
> live inside a "pet" container using https://github.com/cgwalters/coretoolbox
> and I definitely `yum update` inside there, though I do also periodically
> destroy it and re-pull.
>

I also run yum to keep my local runtime updated and I even suggested a
new buildah commit option to make this more efficient:
  https://github.com/containers/buildah/issues/1778

Though this is useful for devel or traditional workstation use-case.
It seems like a fedora image should come with the package
manager, but perhaps it should only be used as a build stage using
an option similar to the --installroot option?

Regards,
-Tristan

> Kubernetes though for sure is about non-pet containers.
>
>> Buildah and Multi-Stage builds do allow you to eliminate
>> these tools, but that is more difficult to do.
>
> multi-stage is easy and obvious for the case of e.g. Golang and Rust single 
> compiled binaries, and it's not too hard to do for other compiled languages 
> (C/C++) as long as you have a notion of `BuildRequires` versus `Requires`.
> For interpreted languages though, yeah, not as worthwhile unless you're 
> pulling in a *lot* of build dependencies (doc tooling?) distinct from your 
> runtime ones.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Colin Walters]

On Wed, Aug 21, 2019, at 7:34 AM, Daniel Walsh wrote:

> I agree.  Entering a container and doing a yum update is an
> Anti-pattern.

This is a complex discussion - I think we need both.  Personally I
live inside a "pet" container using https://github.com/cgwalters/coretoolbox
and I definitely `yum update` inside there, though I do also periodically
destroy it and re-pull.

Kubernetes though for sure is about non-pet containers.

> Buildah and Multi-Stage builds do allow you to eliminate
> these tools, but that is more difficult to do.

multi-stage is easy and obvious for the case of e.g. Golang and Rust single 
compiled binaries, and it's not too hard to do for other compiled languages 
(C/C++) as long as you have a notion of `BuildRequires` versus `Requires`.
For interpreted languages though, yeah, not as worthwhile unless you're pulling 
in a *lot* of build dependencies (doc tooling?) distinct from your runtime ones.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Daniel Walsh]

On 8/21/19 5:00 AM, Tomasz Torcz wrote:
> On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
>> Having a container without a package manager sounds like the worst possible 
>> thing to add to an already poorly implemented solution. In reality, 
>> containers, regardless of what they're running, should be treated as what 
>> they 
>> are, GNU/Linux installs. Each one should be self sufficient from the host 
>> system, so that they can be properly updated using a package manager.
>>
>> Each container should, realistically, be a self contained system.
>   You do not update the container. You rebuild it, creating new image
> with updated components, then you test out new image.
>   Package manager is only needed during the build (in fact, it
> is indispensable at this step) but not during runtime.
>
I agree.  Entering a container and doing a yum update is an
Anti-pattern.  The way container images updates is envisioned is when I
need an updated container, I pull down a brand new image.  Hopefully
this image has gone through a thorough CI/CD system.  The container
image on the build system probably is built using dnf/yum, but those
tools do not necessarily need to be in the final image. Preferably they
would not be there.  Unfortunately in the real world this is not true. 
And the default Dockerfile construct enforces base layers to have dnf
installed.  Buildah and Multi-Stage builds do allow you to eliminate
these tools, but that is more difficult to do.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Tomasz Torcz]

On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
> Having a container without a package manager sounds like the worst possible 
> thing to add to an already poorly implemented solution. In reality, 
> containers, regardless of what they're running, should be treated as what 
> they 
> are, GNU/Linux installs. Each one should be self sufficient from the host 
> system, so that they can be properly updated using a package manager.
> 
> Each container should, realistically, be a self contained system.

  You do not update the container. You rebuild it, creating new image
with updated components, then you test out new image.
  Package manager is only needed during the build (in fact, it
is indispensable at this step) but not during runtime.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[John Harris]

On Tuesday, July 30, 2019 9:05:31 AM MST Christian Glombek wrote:
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual package
> manager inside. You just have the container, mount the config, and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely a
> topic of overall interest!
> 
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
> 
> Christian Glombek
> 
> Associate Software Engineer
> 
> Red Hat GmbH 
>  3.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c!
> 8m2!3d52.5058176!4d13.421332>
> 
> cglom...@redhat.com 
> 
> 
> 
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
> 
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:
> > On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  wrote:
> > > Hi everyone!
> > > 
> > > I'm starting a Minimization Objective [1] focusing on minimising the
> > 
> > installation size of some of the popular apps, runtimes, and other pieces
> > of software in Fedora.
> > 
> > > And there is a new Minimization Team [2] forming. Members of the team
> > 
> > will consult and work with Fedora maintainers, develop tooling and
> > services, generate reports showing the status of the Fedora ecosystem and
> > a
> > comparison with other ecosystems, etc. The goal is to build an environment
> > where it's easy for our maintainers to keep things small over time, it's
> > not just a one-off effort. Please see the Action Plan [3] for more
> > details.
> > 
> > > Want to become a member? Let me know!
> > > 
> > > Cheers!
> > > Adam
> > > 
> > > [1] https://docs.fedoraproject.org/en-US/minimization/
> > > [2] https://docs.fedoraproject.org/en-US/minimization/team/
> > > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
> > 
> > I'm interested, but not just for minimization for the sake of it. We
> > need to be thoughtful about how we are changing the dependency tree.
> > 
> > 
> > 
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!

Having a container without a package manager sounds like the worst possible 
thing to add to an already poorly implemented solution. In reality, 
containers, regardless of what they're running, should be treated as what they 
are, GNU/Linux installs. Each one should be self sufficient from the host 
system, so that they can be properly updated using a package manager.

Each container should, realistically, be a self contained system.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

On Wed, Aug 14, 2019 at 8:49 PM Robbie Harwood  wrote:

> > Here's the scriptlet:
> >
> > %triggerun libs -- krb5-libs < 1.15.1-5
> > if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then
> > sed -i '1i # To opt out of the system crypto-policies
> > configuration of krb5,
> > remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will
> > not be
> > recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf
> > fi
> > exit 0
> >
> > So... there's not actually a call to awk.  And the last version of
> > Fedora to have anything older than 1.15.1 was F28.
>
> Please CC maintainers when discussing their package.  We like it because
> it avoids us getting blindsided by requirements/changes, and sometimes
> we know things about our packages and can be helpful :)
>

Absolutely we need to engage with maintainers when debating changes. Doing
this in isolation would basically mean failure.


>
> There are two uses of awk: one at build-time, and one for the triggers.
> I assume no one cares that I need awk to build.  You're correct that the
> use for the triggers can probably go away since they're aren't any right
> now, but... does this actually matter?  Please file a bugzilla if so.
>
> > We don't supports updates from F28 to F31 (and certainly not updates
> > from F28 when it was rawhide), so the scriptlet is no longer necessary
> > at all.  It has come and gone a few times throughout history but the
> > dependency has remained.
>
> Just because something /can/ go doesn't mean it /should/.


Yep!


> A trigger
> that doesn't fire won't hurt anything, and its removal is more noise to
> filter through.  And there are often other considerations: for instance,
> the el8 spec file is branched from the Fedora one - el7 has a
> 1.15-series krb5.  The upgrade window I have to support is larger than
> what's mandated by Fedora - and that's fine!  It's not causing any
> problems for other things, so it doesn't matter to anyone but me.
>
> Thanks,
> --Robbie
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Robbie Harwood]

> Here's the scriptlet:
>
> %triggerun libs -- krb5-libs < 1.15.1-5
> if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then
> sed -i '1i # To opt out of the system crypto-policies
> configuration of krb5,
> remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will
> not be
> recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf
> fi
> exit 0
>
> So... there's not actually a call to awk.  And the last version of
> Fedora to have anything older than 1.15.1 was F28.

Please CC maintainers when discussing their package.  We like it because
it avoids us getting blindsided by requirements/changes, and sometimes
we know things about our packages and can be helpful :)

There are two uses of awk: one at build-time, and one for the triggers.
I assume no one cares that I need awk to build.  You're correct that the
use for the triggers can probably go away since they're aren't any right
now, but... does this actually matter?  Please file a bugzilla if so.

> We don't supports updates from F28 to F31 (and certainly not updates
> from F28 when it was rawhide), so the scriptlet is no longer necessary
> at all.  It has come and gone a few times throughout history but the
> dependency has remained.

Just because something /can/ go doesn't mean it /should/.  A trigger
that doesn't fire won't hurt anything, and its removal is more noise to
filter through.  And there are often other considerations: for instance,
the el8 spec file is branched from the Fedora one - el7 has a
1.15-series krb5.  The upgrade window I have to support is larger than
what's mandated by Fedora - and that's fine!  It's not causing any
problems for other things, so it doesn't matter to anyone but me.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Daniel Walsh]

On 8/7/19 11:24 AM, Colin Walters wrote:
>
> On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
>> If you want small images, just use buildah.
> Dockerfile-based multi-stage builds are significantly more popular than this 
> and should really be mentioned first.
Buildah supports multi-stage builds as well.
> I'm not saying `buildah` is bad, but...what you're talking about here also 
> encourages using the host as a build root which has various negatives.
>
> And I think the main conversation to have is whether we should introduce 
> something more like
> https://github.com/GoogleContainerTools/distroless
> that basically just has:
>
>  - glibc
>  - ca-certificates
>
> Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's 
> it.
> (While people often say both Rust and golang are statically linked, that's 
> true
>  of the language code, but by default  Rust links to glibc, Go does not, and I
>  think what Rust does is better and should be encouraged, so we want a libc
>  in this "ultramin" container)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Colin Walters]

On Wed, Aug 7, 2019, at 11:25 AM, Colin Walters wrote:
> 
> 
> On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
> > If you want small images, just use buildah.
> 
> Dockerfile-based multi-stage builds are significantly more popular than 
> this and should really be mentioned first.
> 
> I'm not saying `buildah` is bad, but...what you're talking about here 
> also encourages using the host as a build root which has various 
> negatives.
> 
> And I think the main conversation to have is whether we should 
> introduce something more like
> https://github.com/GoogleContainerTools/distroless
> that basically just has:
> 
>  - glibc
>  - ca-certificates

And an interesting discussion here is whether to include e.g. openssl.
golang by default uses custom (statically linked) crypto but it can be 
configured to use openssl.
Rust doesn't have a default but...openssl is at least a common option.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Jason Tibbitts]

> "IG" == Igor Gnatenko  writes:

IG> We can actually get rid out of this using `libcurl-minimal`, but it
IG> is not easy to teach DNF to replace libcurl-minimal with libcurl
IG> without explicit --allowerasing on the command line.

That does prompt the question as to whether dnf itself is required for
"minimal" functionality.  If I'm composing my own container image I
might not really need dnf (or even rpm, really).  Instead of updating
I'd just compose a fresh image.

The question of whether tar is required should be easier.  And of the
3MB of installed size of the tar package, not even 500k is the tar
binary; the rest is localizations and docs.  So the question really does
come down to just how small of an image is actually desired, and how
much packaging work is needed to get there.

Which prompts another question: Are the packages in these images
installed without docs?

IG> It seems that it used to be Requires(triggerun), then for some
IG> reason it was moved into Requires. I don't see any reason why it
IG> would be needed for krb5-libs from the first try.

Here's the scriptlet:

%triggerun libs -- krb5-libs < 1.15.1-5
if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then
sed -i '1i # To opt out of the system crypto-policies configuration of 
krb5, remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will not 
be recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf
fi
exit 0

So... there's not actually a call to awk.  And the last version of
Fedora to have anything older than 1.15.1 was F28.  We don't supports
updates from F28 to F31 (and certainly not updates from F28 when it was
rawhide), so the scriptlet is no longer necessary at all.  It has come
and gone a few times throughout history but the dependency has remained.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Colin Walters]

On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
> If you want small images, just use buildah.

Dockerfile-based multi-stage builds are significantly more popular than this 
and should really be mentioned first.

I'm not saying `buildah` is bad, but...what you're talking about here also 
encourages using the host as a build root which has various negatives.

And I think the main conversation to have is whether we should introduce 
something more like
https://github.com/GoogleContainerTools/distroless
that basically just has:

 - glibc
 - ca-certificates

Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's 
it.
(While people often say both Rust and golang are statically linked, that's true
 of the language code, but by default  Rust links to glibc, Go does not, and I
 think what Rust does is better and should be encouraged, so we want a libc
 in this "ultramin" container)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Igor Gnatenko]

On Wed, Aug 7, 2019 at 1:17 PM Jason Tibbitts  wrote:
>
> I'm on vacation and a few days behind on email, sorry.
>
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
>
> ZJ> Also, there are still some obvious packages to trim:
>
> I wonder if the rpm dependency on curl (the executable, not the library)
> is strictly necessary.  I believe it's only because of the
> %__urlhelpercmd macro.  Are rpm remote file operations considered to be
> mandatory functionality?

https://src.fedoraproject.org/rpms/rpm/pull-request/12

> It would be nice if we could get by without requiring openldap and
> krb5-libs but I suspect we'd have to be Gentoo to reach that level of
> minimization.

We can actually get rid out of this using `libcurl-minimal`, but it is
not easy to teach DNF to replace libcurl-minimal with libcurl without
explicit --allowerasing on the command line.

> It would also be nice to see libdb excised, but it's still a core
> requirement for rpm.  The only other things that need it are cyrus-sasl
> and pam, both of which would do without it with some additional
> subpackage splitting, I think.
>
> It's interesting that gawk is only there because of krb5-libs, but I
> don't see why.  Nothing in that package seems to call awk.  That's about
> 3.5MB.

It seems that it used to be Requires(triggerun), then for some reason
it was moved into Requires. I don't see any reason why it would be
needed for krb5-libs from the first try.

> Is tar considered mandatory?  Nothing appears to depend on it, and its
> 3MB
>
> ZJ> Also, there's a bunch of -devel packages? What pulls those in?
> ZJ> libmount-devel, libblkid-devel, glib2-devel, libassuan,
> ZJ> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
> ZJ> pcre2-devel, zlib-devel.
>
> Seems that's already been fixed.
>
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Jason Tibbitts]

I'm on vacation and a few days behind on email, sorry.

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> Also, there are still some obvious packages to trim:

I wonder if the rpm dependency on curl (the executable, not the library)
is strictly necessary.  I believe it's only because of the
%__urlhelpercmd macro.  Are rpm remote file operations considered to be
mandatory functionality?

It would be nice if we could get by without requiring openldap and
krb5-libs but I suspect we'd have to be Gentoo to reach that level of
minimization.

It would also be nice to see libdb excised, but it's still a core
requirement for rpm.  The only other things that need it are cyrus-sasl
and pam, both of which would do without it with some additional
subpackage splitting, I think.

It's interesting that gawk is only there because of krb5-libs, but I
don't see why.  Nothing in that package seems to call awk.  That's about
3.5MB.

Is tar considered mandatory?  Nothing appears to depend on it, and its
3MB

ZJ> Also, there's a bunch of -devel packages? What pulls those in?
ZJ> libmount-devel, libblkid-devel, glib2-devel, libassuan,
ZJ> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
ZJ> pcre2-devel, zlib-devel.

Seems that's already been fixed.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

On Wednesday, August 7, 2019, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> This has been fixed almost a week ago..
>

Yeah, looking at the container image that's been released doesn't give us
freshest data...

I guess if we generate reports in reaction to Koji builds for example,
consuming content that's not been released yet (part of CI?), that would
give us much more useful data.


>
> On Wed, Aug 7, 2019, 11:58 Adam Samalik  wrote:
>
>>
>>
>> On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek <
>> zbys...@in.waw.pl> wrote:
>>
>>> On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
>>> > Whoop this is great!
>>> > But I wonder why the scratch build sizes have gone up this
>>> dramatically in
>>> > f31?
>>>
>>> Also, there are still some obvious packages to trim:
>>>
>>> No udev, but device-mapper, device-mapper-libs, which are not useful
>>> without udev.
>>>
>>> Also, there's a bunch of -devel packages? What pulls those in?
>>> libmount-devel, libblkid-devel, glib2-devel, libassuan,
>>> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
>>> pcre2-devel, zlib-devel.
>>>
>>
>> Looks like gpme pulls in glib2-devel which in turn pulls in other -devel
>> packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
>>
>>
>>
>>>
>>> Zbyszek
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://docs.fedoraproject.
>>> org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: https://lists.fedoraproject.
>>> org/archives/list/devel@lists.fedoraproject.org
>>>
>>
>>
>> --
>>
>> Adam Šamalík
>> ---
>> Senior Software Engineer
>> Red Hat
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.
>> org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
>> fedoraproject.org
>>
>

-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Peter Robinson]

On Wed, 7 Aug 2019, 10:51 Adam Samalik,  wrote:

>
>
> On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
>> > Whoop this is great!
>> > But I wonder why the scratch build sizes have gone up this dramatically
>> in
>> > f31?
>>
>> Also, there are still some obvious packages to trim:
>>
>> No udev, but device-mapper, device-mapper-libs, which are not useful
>> without udev.
>>
>> Also, there's a bunch of -devel packages? What pulls those in?
>> libmount-devel, libblkid-devel, glib2-devel, libassuan,
>> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
>> pcre2-devel, zlib-devel.
>>
>
> Looks like gpme pulls in glib2-devel which in turn pulls in other -devel
> packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
>

Already fixed



>
>> Zbyszek
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Igor Gnatenko]

This has been fixed almost a week ago..

On Wed, Aug 7, 2019, 11:58 Adam Samalik  wrote:

>
>
> On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
>> > Whoop this is great!
>> > But I wonder why the scratch build sizes have gone up this dramatically
>> in
>> > f31?
>>
>> Also, there are still some obvious packages to trim:
>>
>> No udev, but device-mapper, device-mapper-libs, which are not useful
>> without udev.
>>
>> Also, there's a bunch of -devel packages? What pulls those in?
>> libmount-devel, libblkid-devel, glib2-devel, libassuan,
>> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
>> pcre2-devel, zlib-devel.
>>
>
> Looks like gpme pulls in glib2-devel which in turn pulls in other -devel
> packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
>
>
>
>>
>> Zbyszek
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
> > Whoop this is great!
> > But I wonder why the scratch build sizes have gone up this dramatically
> in
> > f31?
>
> Also, there are still some obvious packages to trim:
>
> No udev, but device-mapper, device-mapper-libs, which are not useful
> without udev.
>
> Also, there's a bunch of -devel packages? What pulls those in?
> libmount-devel, libblkid-devel, glib2-devel, libassuan,
> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
> pcre2-devel, zlib-devel.
>

Looks like gpme pulls in glib2-devel which in turn pulls in other -devel
packages. https://asamalik.fedorapeople.org/fedora-31-base.svg



>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

On Tue, Aug 6, 2019 at 1:34 PM Martin Kolman  wrote:

> On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote:
> > > > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> > > >  wrote:
> > > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > > > > > I've already done some experiments with that. I used multi-stage
> builds
> > > > > > with podman, but it's the same in principle. And yes, the sizes
> are
> > > > > > smaller. What was interesting though that some additional
> packages (ones
> > > > > > that wouldn't appear in the images using the Fedora base image)
> has been
> > > > > > dragged in as dependencies. Some of them are even related to
> hardware. (See
> > > > > > the report [1] and the github repo [2].)
> > > > >
> > > > > It'd be nice to rebase this to F30 or even F31. F29 is not
> interesting
> > > > > anymore.
> > > > >
> > > > > A lot of the stuff in those images seems completely unnecessary:
> > > > > device-mapper, device-mapper-libs, dracut, cpio,
> glibc-all-langpacks,
> > > > > grubby, systemd-bootchart, systemd-udev.
> > > > >
> > > > > > So that might be one area to focus on — to make sure that these
> "from
> > > > > > scratch" installations don't drag unnecessary stuff.
> > > > >
> > > > > Yep, that sounds like a good start. I suspect that F30 might be
> already
> > > > > better in this regard.
> > > >
> > > > Yes quite a bit has happened on the base image since F29, we have
> > > > removed quite a few things and trimmed down the latest rawhide to
> > > > 208MB. I am sure that can still be improved and I welcome any help on
> > > > that :-).
> > >
> > > I've regenerated it for f30 and f31:
> https://asamalik.fedorapeople.org/container-randomness/report.html
> > >
> > > I see the fedora:f31 image is 195 MB, woot!
> >
> > Is there a plan to add some form of CI to monitor this? It would make
> > it easy to monitor ups/downs over time and pick up mistakes that bloat
> > deps by accident.
> I think such CI runs would be very useful even for other "classical"
> deliverables.
>
> If the live image/netinst image/DVD image/installation initrd/etc.
> suddenly grows in size by say 20+ %, this is
> something that should trigger warnings & should be investigated.
>

Yes, I think that could definitely be done!


>
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Martin Kolman]

On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote:
> > > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > > > > I've already done some experiments with that. I used multi-stage 
> > > > > builds
> > > > > with podman, but it's the same in principle. And yes, the sizes are
> > > > > smaller. What was interesting though that some additional packages 
> > > > > (ones
> > > > > that wouldn't appear in the images using the Fedora base image) has 
> > > > > been
> > > > > dragged in as dependencies. Some of them are even related to 
> > > > > hardware. (See
> > > > > the report [1] and the github repo [2].)
> > > > 
> > > > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> > > > anymore.
> > > > 
> > > > A lot of the stuff in those images seems completely unnecessary:
> > > > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> > > > grubby, systemd-bootchart, systemd-udev.
> > > > 
> > > > > So that might be one area to focus on — to make sure that these "from
> > > > > scratch" installations don't drag unnecessary stuff.
> > > > 
> > > > Yep, that sounds like a good start. I suspect that F30 might be already
> > > > better in this regard.
> > > 
> > > Yes quite a bit has happened on the base image since F29, we have
> > > removed quite a few things and trimmed down the latest rawhide to
> > > 208MB. I am sure that can still be improved and I welcome any help on
> > > that :-).
> > 
> > I've regenerated it for f30 and f31: 
> > https://asamalik.fedorapeople.org/container-randomness/report.html
> > 
> > I see the fedora:f31 image is 195 MB, woot!
> 
> Is there a plan to add some form of CI to monitor this? It would make
> it easy to monitor ups/downs over time and pick up mistakes that bloat
> deps by accident.
I think such CI runs would be very useful even for other "classical" 
deliverables.

If the live image/netinst image/DVD image/installation initrd/etc. suddenly 
grows in size by say 20+ %, this is
something that should trigger warnings & should be investigated.


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Zbigniew Jędrzejewski-Szmek]

On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
> Whoop this is great!
> But I wonder why the scratch build sizes have gone up this dramatically in
> f31?

Also, there are still some obvious packages to trim:

No udev, but device-mapper, device-mapper-libs, which are not useful
without udev.

Also, there's a bunch of -devel packages? What pulls those in?
libmount-devel, libblkid-devel, glib2-devel, libassuan,
libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel,
pcre2-devel, zlib-devel.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Clement Verna]

On Mon, 5 Aug 2019 at 10:59, Alexander Bokovoy  wrote:
>
> On ma, 05 elo 2019, Clement Verna wrote:
> >On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:
> >>
> >> >> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> >> >>  wrote:
> >> >> >
> >> >> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> >> >> > > I've already done some experiments with that. I used multi-stage 
> >> >> > > builds
> >> >> > > with podman, but it's the same in principle. And yes, the sizes are
> >> >> > > smaller. What was interesting though that some additional packages 
> >> >> > > (ones
> >> >> > > that wouldn't appear in the images using the Fedora base image) has 
> >> >> > > been
> >> >> > > dragged in as dependencies. Some of them are even related to 
> >> >> > > hardware. (See
> >> >> > > the report [1] and the github repo [2].)
> >> >> >
> >> >> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> >> >> > anymore.
> >> >> >
> >> >> > A lot of the stuff in those images seems completely unnecessary:
> >> >> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> >> >> > grubby, systemd-bootchart, systemd-udev.
> >> >> >
> >> >> > > So that might be one area to focus on — to make sure that these 
> >> >> > > "from
> >> >> > > scratch" installations don't drag unnecessary stuff.
> >> >> >
> >> >> > Yep, that sounds like a good start. I suspect that F30 might be 
> >> >> > already
> >> >> > better in this regard.
> >> >>
> >> >> Yes quite a bit has happened on the base image since F29, we have
> >> >> removed quite a few things and trimmed down the latest rawhide to
> >> >> 208MB. I am sure that can still be improved and I welcome any help on
> >> >> that :-).
> >> >
> >> >
> >> > I've regenerated it for f30 and f31: 
> >> > https://asamalik.fedorapeople.org/container-randomness/report.html
> >> >
> >> > I see the fedora:f31 image is 195 MB, woot!
> >>
> >> Is there a plan to add some form of CI to monitor this? It would make
> >> it easy to monitor ups/downs over time and pick up mistakes that bloat
> >> deps by accident.
> >
> >I started some effort in that sense last year, to have the Fedora CI
> >pipeline to trigger on container builds[0]. Unfortunately the CI
> >pipeline for containers is not working [1] and it seems that nobody
> >has cycles to try to fix it.
> >We could also get some inspiration from what the Docker Hub folks are
> >doing [2][3].
> >
> >And finally I would love to sunset registry.fp.o and just use quay.io
> >as our main registry that would give us for CVE scanning for free
> >using Clair[4] (that would also be one less thing to care about on the
> >infra side), but here again there is some work to be done to make that
> >possible :-)
> Do we have all the same containers in quay.io?
>
> FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
> for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
> quay.io/fedora/ project.

Nope and that's what I meant by saying that this needs some works to
make it possible :-) (Pretty much configure OSBS to publish images to
quay.io instead of registry.fp.o). We also need to make sure that we
can deliver flatpaks from quay.io.

>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Alexander Bokovoy]

On ma, 05 elo 2019, Clement Verna wrote:

On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:


>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages (ones
>> > > that wouldn't appear in the images using the Fedora base image) has been
>> > > dragged in as dependencies. Some of them are even related to hardware. 
(See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>
>
> I've regenerated it for f30 and f31: 
https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!

Is there a plan to add some form of CI to monitor this? It would make
it easy to monitor ups/downs over time and pick up mistakes that bloat
deps by accident.


I started some effort in that sense last year, to have the Fedora CI
pipeline to trigger on container builds[0]. Unfortunately the CI
pipeline for containers is not working [1] and it seems that nobody
has cycles to try to fix it.
We could also get some inspiration from what the Docker Hub folks are
doing [2][3].

And finally I would love to sunset registry.fp.o and just use quay.io
as our main registry that would give us for CVE scanning for free
using Clair[4] (that would also be one less thing to care about on the
infra side), but here again there is some work to be done to make that
possible :-)

Do we have all the same containers in quay.io?

FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
quay.io/fedora/ project.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Clement Verna]

On Sun, 4 Aug 2019 at 18:17, Peter Robinson  wrote:
>
> >> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
> >>  wrote:
> >> >
> >> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> >> > > I've already done some experiments with that. I used multi-stage builds
> >> > > with podman, but it's the same in principle. And yes, the sizes are
> >> > > smaller. What was interesting though that some additional packages 
> >> > > (ones
> >> > > that wouldn't appear in the images using the Fedora base image) has 
> >> > > been
> >> > > dragged in as dependencies. Some of them are even related to hardware. 
> >> > > (See
> >> > > the report [1] and the github repo [2].)
> >> >
> >> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> >> > anymore.
> >> >
> >> > A lot of the stuff in those images seems completely unnecessary:
> >> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> >> > grubby, systemd-bootchart, systemd-udev.
> >> >
> >> > > So that might be one area to focus on — to make sure that these "from
> >> > > scratch" installations don't drag unnecessary stuff.
> >> >
> >> > Yep, that sounds like a good start. I suspect that F30 might be already
> >> > better in this regard.
> >>
> >> Yes quite a bit has happened on the base image since F29, we have
> >> removed quite a few things and trimmed down the latest rawhide to
> >> 208MB. I am sure that can still be improved and I welcome any help on
> >> that :-).
> >
> >
> > I've regenerated it for f30 and f31: 
> > https://asamalik.fedorapeople.org/container-randomness/report.html
> >
> > I see the fedora:f31 image is 195 MB, woot!
>
> Is there a plan to add some form of CI to monitor this? It would make
> it easy to monitor ups/downs over time and pick up mistakes that bloat
> deps by accident.

I started some effort in that sense last year, to have the Fedora CI
pipeline to trigger on container builds[0]. Unfortunately the CI
pipeline for containers is not working [1] and it seems that nobody
has cycles to try to fix it.
We could also get some inspiration from what the Docker Hub folks are
doing [2][3].

And finally I would love to sunset registry.fp.o and just use quay.io
as our main registry that would give us for CVE scanning for free
using Clair[4] (that would also be one less thing to care about on the
infra side), but here again there is some work to be done to make that
possible :-)

[0] - https://src.fedoraproject.org/container/tools/pull-request/6
[1] - https://pagure.io/fedora-ci/general/issue/47
[2] - 
https://github.com/docker-library/official-images/pull/6394#issuecomment-517452501
[3] - 
https://github.com/docker-library/official-images/pull/6394#issuecomment-517454047
[4] - https://github.com/coreos/clair
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Christian Glombek]

Whoop this is great!
But I wonder why the scratch build sizes have gone up this dramatically in
f31?



On Sun, Aug 4, 2019 at 10:59 AM Adam Samalik  wrote:

>
>
> On Sat, Aug 3, 2019 at 11:24 PM Clement Verna 
> wrote:
>
>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage
>> builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages
>> (ones
>> > > that wouldn't appear in the images using the Fedora base image) has
>> been
>> > > dragged in as dependencies. Some of them are even related to
>> hardware. (See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>>
>
> I've regenerated it for f30 and f31:
> https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!
>
>
>>
>> >
>> > Zbyszek
>> >
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Peter Robinson]

>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages (ones
>> > > that wouldn't appear in the images using the Fedora base image) has been
>> > > dragged in as dependencies. Some of them are even related to hardware. 
>> > > (See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>
>
> I've regenerated it for f30 and f31: 
> https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!

Is there a plan to add some form of CI to monitor this? It would make
it easy to monitor ups/downs over time and pick up mistakes that bloat
deps by accident.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

On Sat, Aug 3, 2019 at 11:24 PM Clement Verna 
wrote:

> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > > I've already done some experiments with that. I used multi-stage builds
> > > with podman, but it's the same in principle. And yes, the sizes are
> > > smaller. What was interesting though that some additional packages
> (ones
> > > that wouldn't appear in the images using the Fedora base image) has
> been
> > > dragged in as dependencies. Some of them are even related to hardware.
> (See
> > > the report [1] and the github repo [2].)
> >
> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> > anymore.
> >
> > A lot of the stuff in those images seems completely unnecessary:
> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> > grubby, systemd-bootchart, systemd-udev.
> >
> > > So that might be one area to focus on — to make sure that these "from
> > > scratch" installations don't drag unnecessary stuff.
> >
> > Yep, that sounds like a good start. I suspect that F30 might be already
> > better in this regard.
>
> Yes quite a bit has happened on the base image since F29, we have
> removed quite a few things and trimmed down the latest rawhide to
> 208MB. I am sure that can still be improved and I welcome any help on
> that :-).
>

I've regenerated it for f30 and f31:
https://asamalik.fedorapeople.org/container-randomness/report.html

I see the fedora:f31 image is 195 MB, woot!


>
> >
> > Zbyszek
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Clement Verna]

On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > I've already done some experiments with that. I used multi-stage builds
> > with podman, but it's the same in principle. And yes, the sizes are
> > smaller. What was interesting though that some additional packages (ones
> > that wouldn't appear in the images using the Fedora base image) has been
> > dragged in as dependencies. Some of them are even related to hardware. (See
> > the report [1] and the github repo [2].)
>
> It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> anymore.
>
> A lot of the stuff in those images seems completely unnecessary:
> device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> grubby, systemd-bootchart, systemd-udev.
>
> > So that might be one area to focus on — to make sure that these "from
> > scratch" installations don't drag unnecessary stuff.
>
> Yep, that sounds like a good start. I suspect that F30 might be already
> better in this regard.

Yes quite a bit has happened on the base image since F29, we have
removed quite a few things and trimmed down the latest rawhide to
208MB. I am sure that can still be improved and I welcome any help on
that :-).

>
> Zbyszek
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> I've already done some experiments with that. I used multi-stage builds
> with podman, but it's the same in principle. And yes, the sizes are
> smaller. What was interesting though that some additional packages (ones
> that wouldn't appear in the images using the Fedora base image) has been
> dragged in as dependencies. Some of them are even related to hardware. (See
> the report [1] and the github repo [2].)

It'd be nice to rebase this to F30 or even F31. F29 is not interesting
anymore.

A lot of the stuff in those images seems completely unnecessary:
device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
grubby, systemd-bootchart, systemd-udev.

> So that might be one area to focus on — to make sure that these "from
> scratch" installations don't drag unnecessary stuff.

Yep, that sounds like a good start. I suspect that F30 might be already
better in this regard.

Zbyszek


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Adam Samalik]

I've already done some experiments with that. I used multi-stage builds
with podman, but it's the same in principle. And yes, the sizes are
smaller. What was interesting though that some additional packages (ones
that wouldn't appear in the images using the Fedora base image) has been
dragged in as dependencies. Some of them are even related to hardware. (See
the report [1] and the github repo [2].)

So that might be one area to focus on — to make sure that these "from
scratch" installations don't drag unnecessary stuff.


[1] https://asamalik.fedorapeople.org/container-randomness/report.html
[2] https://github.com/asamalik/container-randomness



On Tue, Jul 30, 2019 at 9:52 PM Daniel Walsh  wrote:

> If you want small images, just use buildah.
>
> ctr=$(buildah from scratch)
> mnt=$(buildah mount $ctr)
> COPY/DnF/make install into $mnt
> buildah config ... $ctr
> buildah commit $ctr NEWIMAGE
> buildah push NEWIMAGE CONTAINERREGGISTY...
>
> If you want to build off of base images, you can probably create them with
> buildah also.
>
> On 7/30/19 12:05 PM, Christian Glombek wrote:
>
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual package
> manager inside. You just have the container, mount the config, and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely a
> topic of overall interest!
>
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
>
> Christian Glombek
>
> Associate Software Engineer
>
> Red Hat GmbH 
>
> 
>
> cglom...@redhat.com 
> 
>
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>
>
>
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:
>
>> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik 
>> wrote:
>> >
>> > Hi everyone!
>> >
>> > I'm starting a Minimization Objective [1] focusing on minimising the
>> installation size of some of the popular apps, runtimes, and other pieces
>> of software in Fedora.
>> >
>> > And there is a new Minimization Team [2] forming. Members of the team
>> will consult and work with Fedora maintainers, develop tooling and
>> services, generate reports showing the status of the Fedora ecosystem and a
>> comparison with other ecosystems, etc. The goal is to build an environment
>> where it's easy for our maintainers to keep things small over time, it's
>> not just a one-off effort. Please see the Action Plan [3] for more details.
>> >
>> > Want to become a member? Let me know!
>> >
>> > Cheers!
>> > Adam
>> >
>> > [1] https://docs.fedoraproject.org/en-US/minimization/
>> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
>> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>> >
>>
>> I'm interested, but not just for minimization for the sake of it. We
>> need to be thoughtful about how we are changing the dependency tree.
>>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Re: Join the new Minimization Team

[Adam Samalik]

Thanks all of you who want to join! Welcome!

I'll add you to the team page [1] and follow up with some organisational
stuff — we might want a weekly meeting to sync, etc. I proposed some
communication channels on the team page as well, let me know if that works
for you.

Cheers!
Adam

[1] https://docs.fedoraproject.org/en-US/minimization/team/

On Tue, Jul 30, 2019 at 3:20 PM Adam Samalik  wrote:

> Hi everyone!
>
> I'm starting a Minimization Objective [1] focusing on minimising the
> installation size of some of the popular apps, runtimes, and other pieces
> of software in Fedora.
>
> And there is a new Minimization Team [2] forming. Members of the team will
> consult and work with Fedora maintainers, develop tooling and services,
> generate reports showing the status of the Fedora ecosystem and a
> comparison with other ecosystems, etc. The goal is to build an environment
> where it's easy for our maintainers to keep things small over time, it's
> not just a one-off effort. Please see the Action Plan [3] for more details.
>
> Want to become a member? Let me know!
>
> Cheers!
> Adam
>
> [1] https://docs.fedoraproject.org/en-US/minimization/
> [2] https://docs.fedoraproject.org/en-US/minimization/team/
> [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Jun Aruga]

I also want to join!

-- 
Jun Aruga | He - His - Him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Igor Gnatenko]

Count me in! I'm not sure if I will have much time to do actual work,
but surely I can help people with advises :)

On Tue, Jul 30, 2019 at 4:58 PM Adam Samalik  wrote:
>
> Hi everyone!
>
> I'm starting a Minimization Objective [1] focusing on minimising the 
> installation size of some of the popular apps, runtimes, and other pieces of 
> software in Fedora.
>
> And there is a new Minimization Team [2] forming. Members of the team will 
> consult and work with Fedora maintainers, develop tooling and services, 
> generate reports showing the status of the Fedora ecosystem and a comparison 
> with other ecosystems, etc. The goal is to build an environment where it's 
> easy for our maintainers to keep things small over time, it's not just a 
> one-off effort. Please see the Action Plan [3] for more details.
>
> Want to become a member? Let me know!
>
> Cheers!
> Adam
>
> [1] https://docs.fedoraproject.org/en-US/minimization/
> [2] https://docs.fedoraproject.org/en-US/minimization/team/
> [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Christian Glombek]

I essentially want what Daniel suggested, as automatable infrastructure.

(There is is larger idea of having images without systemd as well; most
some-kind-of-server rpms that I consider applicable here would have to be
changed a little, too, as they all pull in systemd: e.g. %systemd_ordering
instead of %systemd_requires and ensuring that tmpfiles,users, etc are
created in the container as well (anything encoded in systemd unit files
essentially).)

Christian Glombek

Associate Software Engineer

Red Hat GmbH 


cglom...@redhat.com 



Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander



On Tue, Jul 30, 2019 at 9:52 PM Daniel Walsh  wrote:

> If you want small images, just use buildah.
>
> ctr=$(buildah from scratch)
> mnt=$(buildah mount $ctr)
> COPY/DnF/make install into $mnt
> buildah config ... $ctr
> buildah commit $ctr NEWIMAGE
> buildah push NEWIMAGE CONTAINERREGGISTY...
>
> If you want to build off of base images, you can probably create them with
> buildah also.
>
> On 7/30/19 12:05 PM, Christian Glombek wrote:
>
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual package
> manager inside. You just have the container, mount the config, and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely a
> topic of overall interest!
>
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
>
> Christian Glombek
>
> Associate Software Engineer
>
> Red Hat GmbH 
>
> 
>
> cglom...@redhat.com 
> 
>
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>
>
>
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:
>
>> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik 
>> wrote:
>> >
>> > Hi everyone!
>> >
>> > I'm starting a Minimization Objective [1] focusing on minimising the
>> installation size of some of the popular apps, runtimes, and other pieces
>> of software in Fedora.
>> >
>> > And there is a new Minimization Team [2] forming. Members of the team
>> will consult and work with Fedora maintainers, develop tooling and
>> services, generate reports showing the status of the Fedora ecosystem and a
>> comparison with other ecosystems, etc. The goal is to build an environment
>> where it's easy for our maintainers to keep things small over time, it's
>> not just a one-off effort. Please see the Action Plan [3] for more details.
>> >
>> > Want to become a member? Let me know!
>> >
>> > Cheers!
>> > Adam
>> >
>> > [1] https://docs.fedoraproject.org/en-US/minimization/
>> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
>> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>> >
>>
>> I'm interested, but not just for minimization for the sake of it. We
>> need to be thoughtful about how we are changing the dependency tree.
>>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- 

Re: Join the new Minimization Team

[Daniel Walsh]

If you want small images, just use buildah.

ctr=$(buildah from scratch)
mnt=$(buildah mount $ctr)
COPY/DnF/make install into $mnt
buildah config ... $ctr
buildah commit $ctr NEWIMAGE
buildah push NEWIMAGE CONTAINERREGGISTY...

If you want to build off of base images, you can probably create them
with buildah also.

On 7/30/19 12:05 PM, Christian Glombek wrote:
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual
> package manager inside. You just have the container, mount the config,
> and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely
> a topic of overall interest!
>
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
>
> Christian Glombek
>
> Associate Software Engineer
>
> Red Hat GmbH 
>
> 
>
> cglom...@redhat.com 
>
> 
>
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, 
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>
>
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  > wrote:
>
> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  > wrote:
> >
> > Hi everyone!
> >
> > I'm starting a Minimization Objective [1] focusing on minimising
> the installation size of some of the popular apps, runtimes, and
> other pieces of software in Fedora.
> >
> > And there is a new Minimization Team [2] forming. Members of the
> team will consult and work with Fedora maintainers, develop
> tooling and services, generate reports showing the status of the
> Fedora ecosystem and a comparison with other ecosystems, etc. The
> goal is to build an environment where it's easy for our
> maintainers to keep things small over time, it's not just a
> one-off effort. Please see the Action Plan [3] for more details.
> >
> > Want to become a member? Let me know!
> >
> > Cheers!
> > Adam
> >
> > [1] https://docs.fedoraproject.org/en-US/minimization/
> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
> >
>
> I'm interested, but not just for minimization for the sake of it. We
> need to be thoughtful about how we are changing the dependency tree.
>
>
>
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Troy Dawson]

On Tue, Jul 30, 2019 at 7:58 AM Adam Samalik  wrote:
>
> Hi everyone!
>
> I'm starting a Minimization Objective [1] focusing on minimising the 
> installation size of some of the popular apps, runtimes, and other pieces of 
> software in Fedora.
>
> And there is a new Minimization Team [2] forming. Members of the team will 
> consult and work with Fedora maintainers, develop tooling and services, 
> generate reports showing the status of the Fedora ecosystem and a comparison 
> with other ecosystems, etc. The goal is to build an environment where it's 
> easy for our maintainers to keep things small over time, it's not just a 
> one-off effort. Please see the Action Plan [3] for more details.
>
> Want to become a member? Let me know!
>
> Cheers!
> Adam
>
> [1] https://docs.fedoraproject.org/en-US/minimization/
> [2] https://docs.fedoraproject.org/en-US/minimization/team/
> [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>

Hi Adam,
Please put me on the list of people who would like to be on the team.
I'm not sure how Paul would feel about me working on the minimization
efforts (I'm currently doing EPEL stuff), but I feel it would fit in
with my RHEL9 and Fedora IoT efforts.  Plus, I'm always trying to get
installs and systems as small as possible.
Troy Dawson
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Christian Glombek]

I would be especially interested in minimizing container images.
I'd like to e.g. see purpose-built containers without an actual package
manager inside. You just have the container, mount the config, and go.
We're also trying to minimize Fedora CoreOS[1], so this is definitely a
topic of overall interest!

[1] https://github.com/coreos/fedora-coreos-tracker/issues/186

Christian Glombek

Associate Software Engineer

Red Hat GmbH 


cglom...@redhat.com 



Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander



On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:

> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  wrote:
> >
> > Hi everyone!
> >
> > I'm starting a Minimization Objective [1] focusing on minimising the
> installation size of some of the popular apps, runtimes, and other pieces
> of software in Fedora.
> >
> > And there is a new Minimization Team [2] forming. Members of the team
> will consult and work with Fedora maintainers, develop tooling and
> services, generate reports showing the status of the Fedora ecosystem and a
> comparison with other ecosystems, etc. The goal is to build an environment
> where it's easy for our maintainers to keep things small over time, it's
> not just a one-off effort. Please see the Action Plan [3] for more details.
> >
> > Want to become a member? Let me know!
> >
> > Cheers!
> > Adam
> >
> > [1] https://docs.fedoraproject.org/en-US/minimization/
> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
> >
>
> I'm interested, but not just for minimization for the sake of it. We
> need to be thoughtful about how we are changing the dependency tree.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Neal Gompa]

On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  wrote:
>
> Hi everyone!
>
> I'm starting a Minimization Objective [1] focusing on minimising the 
> installation size of some of the popular apps, runtimes, and other pieces of 
> software in Fedora.
>
> And there is a new Minimization Team [2] forming. Members of the team will 
> consult and work with Fedora maintainers, develop tooling and services, 
> generate reports showing the status of the Fedora ecosystem and a comparison 
> with other ecosystems, etc. The goal is to build an environment where it's 
> easy for our maintainers to keep things small over time, it's not just a 
> one-off effort. Please see the Action Plan [3] for more details.
>
> Want to become a member? Let me know!
>
> Cheers!
> Adam
>
> [1] https://docs.fedoraproject.org/en-US/minimization/
> [2] https://docs.fedoraproject.org/en-US/minimization/team/
> [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
>

I'm interested, but not just for minimization for the sake of it. We
need to be thoughtful about how we are changing the dependency tree.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org