14:16:21 <haraldh> #startmeeting Fedora Base Design Working Group (2015-08-03)
14:16:21 <zodbot> Meeting started Mon Aug  3 14:16:21 2015 UTC.  The chair is haraldh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:16:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:16:30 <haraldh> #meetingname  Fedora Base Design Working Group
14:16:30 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
14:16:33 <haraldh> #chair haraldh msekleta jreznik dgilmore vpavlin masta dwalsh lnykryn
14:16:33 <zodbot> Current chairs: dgilmore dwalsh haraldh jreznik lnykryn masta msekleta vpavlin
14:16:38 <haraldh> ping msekleta jreznik dgilmore vpavlin masta dwalsh lnykryn
14:16:50 <msekleta> hi everyone
14:16:52 <lnykryn> hello
14:16:55 <haraldh> hi
14:16:58 <jreznik> hey everyone!
14:17:09 <vpavlin> Hello..
14:17:26 <dgilmore> hey all
14:17:41 <jreznik> so it's time again :)
14:18:09 <haraldh> oh wow
14:18:12 <haraldh> so many :)
14:18:37 <haraldh> #topic Define the minimal install
14:18:41 * jsmith lurks
14:18:56 <haraldh> you probably saw my email about the systemd deps on fedora-devel ML
14:19:19 <haraldh> I just took systemd deps, because apparently systemd is in 99,99% in the minimal set
14:20:03 <haraldh> so, one thing I noticed is: ${pkg}-libs sometimes pulls in a lot of other stuff
14:20:11 <haraldh> which is not what I would expect
14:20:51 <haraldh> e.g. device-mapper-libs pulling in device-mapper
14:21:17 <haraldh> in my small world, linking against a library only means, that I might use the functionality
14:21:43 <haraldh> so, in this case, systemd has device-mapper support, but if there is no device, it should not hard depend on the rest
14:21:49 <haraldh> what do you think?
14:22:40 <haraldh> side note: I have to leave on 15:25 UTC, so maybe someone else can take over the meeting at this time?
14:24:04 <vpavlin> I can take notes and call Meetbot commands;)
14:24:27 <haraldh> the endmeeting and link posting would be cool
14:24:46 <vpavlin> haraldh: np with that
14:25:29 <haraldh> Another thing to maybe enforce for the minimal install is soft deps.
14:25:48 <haraldh> "Recommends:" instead of "Requires:"
14:25:52 <vpavlin> #link https://lists.fedoraproject.org/pipermail/devel/2015-July/212859.html
14:26:36 <haraldh> So, we might want to request a packaging guideline for the @core comps packages
14:26:49 <haraldh> so, that we can enforce soft deps
14:27:07 <dgilmore> haraldh: sorry I have about 20 meetings on the morning
14:27:37 <haraldh> at least for things, which do not break functionality badly
14:27:40 <vpavlin> #idea request a packaging guideline for the @core comps packages using recommends rather than requires
14:28:58 <msekleta> e.g. NetworkManager now Requires: dnsmasq, I think that it should use Recommends instead
14:29:18 * masta is here
14:30:59 <haraldh> vpavlin, as we have you in the meeting :) what is the "minimal" set for docker ?
14:31:04 <masta> Hey folks, I'm going to try and participate but got a lot going on... child home from day care, and supervising painters in the house, plus a bazillion meetings.
14:31:24 <vpavlin> haraldh: Good question, I haven't checked for a while:)
14:31:56 <vpavlin> haraldh: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-docker-base.ks
14:32:27 <haraldh> that includes systemd?
14:32:31 * vpavlin should remove #fakesystemd:-)
14:32:46 <vpavlin> Yes, it's pulled in by something...dnf, I gues..
14:32:47 <vpavlin> guess
14:32:58 <lnykryn> they are calling systemctl at the end
14:33:05 <haraldh> side question: why do you need dnf in the container?
14:33:16 <haraldh> for updates?
14:33:20 <lnykryn> and layers
14:33:25 <haraldh> hmm, ok
14:33:38 <haraldh> do we have a "minimal" use case without dnf?
14:34:39 <vpavlin> haraldh: As you wouldn't be able to add anything to the image..I don't thing not-having dnf makes sense (at least until someone fixes the installation from outside)
14:34:57 <vpavlin> I've heard about some attempts, but no idea how successful those were
14:35:12 <haraldh> well in a container image, I can have the package DB outside of the container
14:35:25 <haraldh> no need for the container to be bloated with it
14:35:37 <haraldh> in theory
14:36:07 <msekleta> just fyi I just installed docker base image package set and it is 156 packages
14:36:25 <haraldh> wow, that's a lot already
14:36:37 <haraldh> vpavlin, I guess you want that to be smaller also?
14:36:45 <vpavlin> haraldh: Yes, in theory:-) IIRC it brings some problems:)
14:37:03 <msekleta> trusty emacs-filesystem present of course :)
14:37:08 <haraldh> :)
14:37:43 <vpavlin> Smaller is always better in case of Docker, I think:-)
14:39:01 <vpavlin> #info docker base image package set is 156 packages
14:42:29 <haraldh> @core comps has the title "Smallest possible installation"
14:42:43 <haraldh> maybe we should change that
14:42:50 <vpavlin> haraldh: I guess that's how it started...:-)
14:42:51 <haraldh> the definition of the package set
14:43:12 <haraldh> so, I see the following use case
14:43:32 <haraldh> container, bare metal
14:43:44 <haraldh> with either rpm/dnf package management or not
14:43:54 <haraldh> container, qemu, bare metal
14:44:02 <haraldh> container, virt, bare metal
14:44:35 <msekleta> #link http://fpaste.org/251022 Packages present in docker base image
14:44:41 <haraldh> I might see cases, where dnf/rpm is not needed
14:46:02 <vpavlin> haraldh: It might not be needed for some images - virt/embedded...but you still need a way how to get your stuff there..
14:46:06 <haraldh> and honestly "bash" might not even be needed in the docker case :)
14:46:35 <haraldh> vpavlin, well, you can easily deploy binary images without the DB inside the image
14:46:54 <haraldh> be it btrfs snapshots
14:46:59 <haraldh> or container images
14:47:32 <haraldh> as long as the binary image is somehow linked to the package list
14:47:54 <vpavlin> haraldh: I mean, for Docker image - if there is no dnf/yum in the image and your app is packaged as rpm (or simply has rpm dependency) how do you get it there?
14:48:43 <haraldh> rpm --root
14:49:03 <vpavlin> haraldh: I think that's problematic for Docker images
14:49:30 <lnykryn> haraldh: you can't use that in dockerfile
14:49:32 <haraldh> well, think ahead... at some point in time there may be other container image build tools
14:50:20 <vpavlin> I heard about some attempts of mounting rpmdb and installation tools in the image and thus having sort of -devel and -prod images where -devel carries the DB and tools, and -prod carries the app
14:50:29 <vpavlin> But I am not sure if this idea is still alive
14:50:59 <vpavlin> haraldh: Yes, I agree that if we consider other tools/formats than Docker, then your approach is perfectly valid
14:53:08 <lnykryn> how would you install a package to fedora base image on debian host?
14:56:36 <haraldh> lnykryn, all I am saying is, that the resulting installation does not have to have rpm
14:56:47 <haraldh> for whatever use case you want that
14:57:02 <haraldh> we should not holding that back
14:57:14 <haraldh> by enforcing a hard dep on rpm/dnf
14:58:06 <haraldh> e.g. my particles images do not need that
14:58:27 <haraldh> because they would be signed anyway and not be extendable
14:59:37 <haraldh> same thing would probably apply to atomic, if we really handle it as an "atomic" OS :)
15:00:08 <vpavlin> haraldh: Atomic does not have yum/dnf, but rpm is still there
15:00:14 <lnykryn> yes, but the problem is that docker workflow is not designed that way
15:00:46 <lnykryn> if you want to deploy a smaller image you can always remove rpm, yum and squash the layers
15:00:48 <haraldh> yeah, forget docker.. maybe the container tool of 2020 will be another one
15:01:11 <vpavlin> haraldh: What you are proposing would requires to drop the layering concept, I think
15:01:23 <haraldh> hm?
15:01:24 <haraldh> why?
15:01:42 <haraldh> the rpmdb could live outside of the image
15:02:04 <vpavlin> Do you think it would be maintainable solution for users?
15:02:12 <haraldh> to run the image you don't have it
15:02:24 <haraldh> so you would reduce the image size
15:02:39 <masta> I think @core comps should remain titles "smallest install" mostly because the others are orthogonal to it, even if they are smaller
15:03:05 <haraldh> what I was thinking of is:
15:04:19 <haraldh> absolut-minimal, docker=absolut-minimal+dnf, virt-minimal=docker+kernel, bare-metal=virt-minimal+firmware
15:04:25 <haraldh> s.th. like that
15:05:14 <vpavlin> haraldh: makes sense to me
15:05:31 <vpavlin> #idea haraldh: what I was thinking of is: absolut-minimal, docker=absolut-minimal+dnf, virt-minimal=docker+kernel, bare-metal=virt-minimal+firmware
15:05:44 * lnykryn forgets that the topic is still minimal instalation and not docker package set
15:05:54 <dgilmore> haraldh: absolute-minimal should be dnf and kernel
15:06:02 <haraldh> huh?
15:06:04 <lnykryn> dgilmore: no
15:06:18 <haraldh> dgilmore, I can run containers without kernel
15:06:45 <dgilmore> haraldh: kernel can be exclude for those things
15:07:15 <dgilmore> haraldh: I think today though the tooling that makes the deliverables chooses to install a kernel or not
15:07:17 <haraldh> that's why I called it absolute-minimal and not "minimal" :)
15:07:21 <dgilmore> and which kernel to install
15:07:54 <dgilmore> so you could drop the kernel from anything
15:07:58 <dgilmore> everythign
15:08:02 <dgilmore> everything
15:08:20 <dgilmore> and leave it to the tooling to decide when a kernel is needed
15:08:43 <dgilmore> but the absoute minimal should give you the ability to install more
15:08:55 <haraldh> and why dnf? I explained, that in some use cases you would not want dnf/rpm
15:08:59 <dgilmore> which is why it should have dnf
15:09:39 <dgilmore> haraldh: I missed any explanation you gave, but afaik there is no way to not have dnf/rpm and have things be usable
15:09:40 <haraldh> where the update mechanism is another one than dnf/rpm
15:10:11 <haraldh> huh? I can make an update with btrfs snapshots just fine
15:10:25 <dgilmore> haraldh: atomic is defined by atomic and outside of our view
15:10:26 <haraldh> the update does not have to happen on the machine the image is running on
15:10:54 <haraldh> why should I enforce s.th. like that?
15:11:08 <haraldh> I mean, we are not talking about the fedora-workstation package set
15:11:13 <haraldh> but the minimal one
15:11:57 <dgilmore> haraldh: I am going to bow out because I have been in two other meeting all morning and am clearly missing a lot of background info
15:16:03 <vpavlin> haraldh: I agree with your approach to this..makes a lot of sense
15:16:47 <vpavlin> Then the absolut-minimal should be really the smallest possible, docker one can get a bit more stuff in (not only dnf, if required)
15:16:59 <haraldh> what do you guys think about my *-libs issue?
15:17:49 <haraldh> would it make sense to enforce the removal of hard deps to other packages for *-libs ?
15:18:12 <haraldh> ofc not for reqs of other *-libs
15:19:37 <vpavlin> The question is if (for your example) device-mapper-libs actually use (anything from) device-mapper package
15:20:00 <vpavlin> which would make it hard to fix this -libs problem
15:20:40 <haraldh> as I said, if the component is not present, the lib funcs should probably return with an error
15:21:14 <vpavlin> right
15:21:47 <haraldh> ok, I see the case of multilibs
15:22:01 <haraldh> that's why it was split in the first place
15:23:49 <haraldh> ok, guys.. have to leave.. feel free to continue with the other topcs
15:23:52 <haraldh> topics
15:23:59 <haraldh> see you next week
15:24:15 <vpavlin> See you
15:24:32 <msekleta> bye haraldh
15:27:28 <vpavlin> Do we want to continue with minimal install topic or move further?
15:27:32 <vpavlin> *forward
15:29:52 <vpavlin> ok...
15:30:00 <vpavlin> #topic Open Floor
15:30:08 <vpavlin> Anybody anything?:-)
15:31:12 * masta has nothing
15:31:40 <lnykryn> nope
15:31:58 <vpavlin> Heh, seems like we are lost with haraldh:-)
15:32:03 <vpavlin> *without
15:32:15 <lnykryn> see you next week
15:32:19 <vpavlin> #endmeeting