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