16:08:56 #startmeeting fpc 16:08:56 Meeting started Thu May 21 16:08:56 2015 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:08:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:08:57 #meetingname fpc 16:08:57 #topic Roll Call 16:08:57 The meeting name has been set to 'fpc' 16:09:01 #chair tibbs 16:09:01 Current chairs: geppetto tibbs 16:09:06 #chair tomspur 16:09:06 Current chairs: geppetto tibbs tomspur 16:09:10 #chair orionp 16:09:10 Current chairs: geppetto orionp tibbs tomspur 16:09:13 #chair SmootherFrOgZ 16:09:13 Current chairs: SmootherFrOgZ geppetto orionp tibbs tomspur 16:09:17 #chair racor 16:09:17 Current chairs: SmootherFrOgZ geppetto orionp racor tibbs tomspur 16:09:24 hi 16:09:32 #chair Rathann 16:09:32 Current chairs: Rathann SmootherFrOgZ geppetto orionp racor tibbs tomspur 16:09:59 mbooth not here? 16:10:46 #topic Schedule 16:10:48 https://lists.fedoraproject.org/pipermail/packaging/2015-May/010658.html 16:11:10 jzeleny-home: ffesti: You ready? 16:11:15 #topic #531 Discuss guidelines for use of weak dependencies 16:11:16 .fpc 531 16:11:16 https://fedorahosted.org/fpc/ticket/531 16:11:19 geppetto: #531 (Establish guidelines for use of weak dependencies in package specifications for F23.) – fpc - https://fedorahosted.org/fpc/ticket/531 16:11:28 yup 16:12:02 This is indeed a bit more fleshed out than the previous proposal. 16:12:07 here 16:12:23 I wonder if the people who submitted this are even aware of the previous proposal. 16:12:41 damit I read ticket 492 for preparation... 16:12:43 tibbs: The reverse deps one? Yeh, they reference it, right? 16:13:04 tibbs: yeh, 492 is the first line :) 16:13:20 Ah, that's the one. 16:13:32 I was searching the wrong way, trying to find the old proposal first. 16:13:41 * geppetto nods 16:14:10 Anyway, my opinion is pretty much the same: documenting it is good; if it works in a defined way with the tools we have then I've no problem. 16:14:39 documenting when and why would be even better 16:14:44 with examples, of course 16:14:45 Although I do hope as well that they don't screw me over in practice. 16:15:29 yeh, the biggest worry I have is that if we aren't that strict about it they'll be a lot of cases where packagers randomly choose soft-requires/requires … or soft-requires/nothing. 16:15:30 tibbs: My expectations are the worst. 16:16:04 geppetto: Indeed, which is why I'm kind of troubled by people just going ahead and stuffing this stuff into their packages already. 16:16:15 At least if it gets documented something can happen. 16:17:42 Anyway, have I been dumb again and missed the proposed draft? 16:17:59 There isn't a proposed draft 16:18:13 OK, good, so I'm not that dumb. 16:18:13 That's why I changed the ticket to discuss guidlines 16:18:34 ^ what geppetto said 16:18:37 ;) 16:18:45 at this point I suspect we need to have some agreement on the level of detail of the guidelines 16:19:01 Hopefully the main thing we can get today is some kind of "this is a high level of what the draft should say" 16:19:16 sounds good 16:19:31 Half of the ticket is about whether we actually need to say "don't use this stuff now". 16:20:17 well, I started https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies a while ago 16:20:18 So the 3 possibilities I see are: 1) "Go use them to do whatever, and try not to be too crazy, this is what they do" … and look at what happened in a few months 16:20:33 But at a "high level", I'd prefer to say that this kind of thing should be used sparingly. 16:20:37 I'm tempted to try to ban them to force the creating of some good guidelines 16:20:47 If I had known about this meeting more than 2 hours in advance I might have polished it up a bit 16:20:49 2) A list of problems people think they can solve with them, and have recipe type things of "Do XYZ to solve ABC problm" 16:21:02 or something way more complicated, that I doubt anyone wants to write ;) 16:22:15 I actually kind of like #2. 16:22:58 agreed 16:23:00 #2 seems good, ffesti's doc seems like a template in that direction 16:23:02 me too 16:23:03 ffesti: I think Recommends/Suggests get installed by default unless user explicitly configures dnf not to 16:23:10 as long as we do not have boolean deps yet the cases are actuallynot that complicated 16:23:23 ffesti: you have package preference on your page … do you think that's a good use of soft-requires, and won't need rich-deps? 16:23:30 To me the real issue is with the default behavior of the tools, what ends up just being ignored and what ends up the same as Requires:? 16:23:32 I'm in favour of #2 as well 16:23:43 jsilhan: hey, a dnf dev too :) 16:23:47 Rathann: Souldn't that be Recommends/Supplements (instead Suggests)? 16:23:57 tomspur: correct, my mistake 16:24:29 geppetto: to be honest, the preference stuff is just a side effect in my opinion and the preference should be actually handled by a completely different mechanism 16:24:49 tibbs: Recommends is like Requires when installing, but you can uninstall whatever was recommended afterwards and there will be no broken deps, so it's different 16:24:56 jzeleny-home: Yeh, I would agree … but that seems to be the first usecase everyone else looks to solve, so :-o 16:25:04 The main use case for now is replacing Requires by Recomment where the package is not strictly required but wanted by the requiering package 16:25:06 people may want to compare their packages to those in debian as well 16:25:11 geppetto: yes, unfortunately 16:25:18 Rathann: Right, but to most people that's going to look just like Requires:. 16:25:32 Main reason is allowing smaller installations with a reduced feature set 16:25:40 like for containers or VMs 16:26:02 So treat it pretty much like Requires:. And Suggests:, well, it is just a hint and hopefully doesn't actually do anything by default, so packagers can throw it in without much issues. 16:26:22 speak of the devil - error: line 44: Unknown tag: Recommends: python-theano - epel7 16:26:22 ffesti: ok … that sounds simpler than it is. How do we define doesn't work? … and doing that conflicts heavily with people adding soft-requires to bring in more stuff 16:26:28 In general Forward deps should be used 16:26:42 unless the main package really should not care 16:27:00 I'd say: Use Recommends: for any packages that your package should have installed as dependencies by default, but doesn't crash without 16:27:19 tibbs: pretty much. The idea there is to have the possibility to query the package and see if there is something related that can be also installed. Sort of an "FYI" if you will 16:27:19 Rathann, exactly 16:27:24 Rathann: Hey, I like that. 16:27:45 Rathann: so if not having something as requires means the program will only really do --version and --help … that's fine? 16:27:59 geppetto: "by default" 16:28:19 geppetto: Actually in a lot of cases, that might actually be fine. 16:28:25 Rathann: Ok, so the program should do it's "default" operation, without any recommends being installed? 16:28:33 geppetto, yes, If the package does not crash 16:28:42 It's going to be a judgment call anyway. 16:28:53 for things like containers people might want to have more controll over what modules they actually install 16:28:57 we should find an example :) 16:29:06 it's easier to explain with a good one 16:29:08 tibbs: well there's a pretty big difference between "doesn't crash" and "does something useful" 16:29:43 geppetto: I'd say Requires and Recommends should cover default user experience for a package 16:30:20 geppetto, but if a package can do multiple things (like en(decoding multiple formats) it is ok to not require any of the modules 16:30:25 Rathann: sounds good 16:30:34 it will do something useful by default 16:30:42 Rathann: and Requires only should cover some minimal set 16:30:47 exactly 16:30:47 I actually have one specific example 16:30:49 only people wanting more controll can restrict the packages that get installed 16:30:51 systemd in containers 16:31:12 the default systemd is a pretty big steam machine 16:31:12 oh, gstreamer stack could be a good example 16:31:24 but most of its functionality is not required in containers 16:31:31 also, libreoffice 16:31:46 and texlive 16:31:59 basically all documentation and examples 16:31:59 BTW, who is the DNF maintainer now? I have had trouble keeping track. 16:32:06 jzeleny-home: But if you install that minimal set on a real install … nothing works, right? 16:32:15 I see the example for texlive, but now for the other two... 16:32:15 tibbs: meet jsilhan 16:32:35 yeah, thats me 16:32:43 OK, cool. 16:32:50 geppetto: pretty much ... the expectation is that user uninstalling Recommended packages knows what is he doing 16:33:07 I just wanted to make sure that someone who understood all of the details of the DNF implementation was onboard. 16:33:10 geppetto, that's what all those container guys want if I understod them correctly 16:33:36 jzeleny-home: That seems like a pretty big bar to get over … uninstalling packages that are happy to go (because they are only recommended), and then your system is unbootable … that doesn't seem like a good idea to me 16:34:06 tibbs, well it's about depsolver implementation - not exactly dnf thing 16:34:20 this is libsolv job but we can tweak it a bit 16:34:21 This sounds similar like gvim Recommending X, which seems odd to allow installing gvim without any X 16:34:27 But it's exactly a dnf thing. 16:34:30 ffesti: Yeh, but people want crazy things … they already have a fakesystemd, right? And that seems like a much better solution. 16:34:33 so gstreamer could have Recommends: gstreamer-plugins-good and Suggests: gstreamer-plugins-bad-free 16:34:36 Because that's the user interface people are going to see. 16:35:01 Exactly what all of the relevant tools will do is entirely the point of this exercise. 16:35:02 hm I wonder why pidgin, gnomebaker and farstream have explicit requires on gstreamer-plugins-good 16:36:16 geppetto: BTW, wasn't it only some yum protection plugin that kept yum uninstall from making your system unbootable? 16:36:41 geppetto, well, it depends on the package. For systemd and other things and can make the system no longer boot it might be worth comming up with a special handling 16:36:54 geppetto, but for things like documentation... 16:36:59 tibbs: Kind of, before the protection stuff the tools would let you confirm removing your entire system 16:37:23 tibbs: But at least you got the hint that removing bash (or whatever) was going to take 666 other packages with it 16:37:35 tibbs: No, IIRC "plain yum" had some protection, as well as rpm itself also has(d) some protection 16:37:45 geppetto: you have a point ... I guess it's up to the maintainer and his judgement; we also have mechanisms to protect components which can make your system unbootable if uninstalled 16:37:49 tibbs: The problem is that with recommends, you could try removing XYZ and only XYZ would go … even though systemd now can't boot your system 16:38:01 rpm does not a protection against removing packages 16:38:06 We're kind of down into per-product configuration land here, where package dependencies alone aren't sufficient to express what's actually needed. 16:38:31 it is just not practical to remove the complete system with rpm as you need to add all packages at the command line 16:38:42 tibbs: right, which is why the systemd vs. fakesystemd solves this better … one product can install fakesystemd and it won't have the requires. 16:38:45 ffesti: rpm had a list of unremovable packages. 16:38:46 IMO 16:40:01 geppetto: I disagree, systemd should be able to trim down its strict dependency set and boot-critical stuff should be added to protectbase or something like that for Workstation product or nonproduct configuration 16:40:24 if the minimal dep set still allows stuff to work in container scenario 16:40:30 weak deps isn;t cure for anything. You can split systemd into many provides and require only the needed features 16:40:31 then I'm all for it 16:41:02 * anything -> everything 16:41:12 Rathann: So kickstart + minimal + no recommends == no boot … you think that's good? 16:41:38 tibbs: I know you wanted to do something like that … you happy with having to manually add systemd stuff in? 16:41:40 geppetto, you need to add those packages to minimal 16:41:56 for bootable system 16:41:59 obviously when you run kickstart you should know what you're doing, but the minimal set should result in a working container 16:42:10 ffesti: Dont' containers use minimal though? 16:42:33 hmm, may be you need to add it to something else 16:43:02 if we use minimal for containers then yes the result should be a unbootable system 16:43:06 geppetto: Oh, you mean a minimal server install? 16:43:21 but we need another group we use for bare metal installation 16:43:33 exactly 16:43:40 Yeah, I don't particularly have a problem with trying to make sure that /sbin/init is there. 16:43:48 tibbs: yeh, you'd mentioned wanting to just turn soft-requires off in your kickstarts 16:44:14 Yes. 16:44:58 I think if you want a system with the absolutely minimal dependency set, you kind of get to figure out how to actually drive that. 16:45:12 my guess is that people will need finer controll than just switching weak deps on and off globally for the whole system 16:45:39 so they will run some part of the installation with them switched on and some with them switched off 16:45:48 Ok, so given that I think we want the "by default" to be a much looser "in some condition" type thing. So that we can say moving a bunch of requires to recommends is fine if stuff works in the container, even though it doesn't anywhere else. 16:46:09 ffesti: How would that be possible, it's one transaction? 16:46:12 I wouldn't propose multiple levels of "Recommends:" for fear of feeling pain via IRC. 16:46:35 But if you need finer control, you just specify the deps you actually want. 16:47:02 ffesti: I think people will need a "per installation/transaction" --with/no-recommends 16:47:15 well, you run a few dnf commands 16:47:18 racor: in theory that's possible already with --setopt 16:47:50 More than that and I think you want a better UI than just yes/no. 16:48:07 Eg. dselect vs. apt-get 16:48:31 geppetto: ... vs. aptitude 16:49:23 I would suggest to actually have some weak deps first and worry abut a UI later 16:49:41 yeh, maybe I have the names wrong … there's the default one that just installs all of them or not (pretty sure that's apt-get), then the one which shows a tree and lets you check/uncheck individual recommends 16:50:19 ffesti: agreed 16:50:46 ffesti: We already have some. 16:51:03 The thing is that there are two opposing trends: #1 do not bother the user with all those details 2# More control over what gets installed 16:51:22 ffesti: Some folks went ahead and "just did it". 16:51:32 yup 16:51:48 ffesti: Right, and we have two options … and it looks like people want to go further in each direction with each option 16:51:50 I don't think it's acceptable to worry about a UI later. 16:52:11 yep, repoquery filters and weak deps switch should come first 16:52:18 At least the general concepts of how that UI would work need to be considered before just going ahead and doing things. 16:52:32 well, there will of course be a basic UI for kickstart and dnf 16:52:40 But I don't think we need a fully functioning UI in every one of the tools before we approve guidelines. 16:52:40 So we'd have: 1) soft-requires turned off … you have lots of control, but have to be very careful or stuff won't work. 2) soft-requires on … you have little control and nethack gets installed when you installl bash ;) 16:53:11 geppetto: How are you defining soft-requires? 16:53:11 Which I'm mostly fine with, if someone wants to write the policy. 16:53:27 tibbs: the dnf option 16:53:29 Recommends: or Suggests:? 16:53:57 tibbs: the first one 16:54:32 Soft dependencies and really floppy squishy dependencies. 16:56:00 So where are we at? 16:56:23 I _think_ we are mostly agreed on what I said … although I didn't see any agreements :-o 16:56:32 So someone just needs to write that up in a policy 16:57:41 Is there a meeting next week? 16:57:49 yeh, there should be 16:58:21 Ok, I am PTO half of the comming weak but I should be able to polish https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies up til next Thursday 16:58:32 In any draft, I'd like to see reasonable examples, a provision for discussing how tooling deals with the various softnesses of dependencies in general terms, and some kind of admonition that at least Recommends: should be used sparingly where needed to trim the dependency list. 16:58:57 agreed 16:59:42 geppetto: OT, but while we're at it, I won't be able to attend the next two Thursdays (being on vacation). 16:59:51 racor: ok 17:00:06 tibbs, should the tooling stuff really go into the packaging policy? 17:00:25 The general concepts, yes. 17:00:33 ok 17:00:44 Specific information, not really; we don't want the guidelines turning into documentation for DNF. 17:00:48 ffesti: At least the option name should be easily accessible, so that people can find it. 17:01:02 ok, will put them in 17:01:30 #action ffesti Work on https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies for next meeting 17:01:43 The guidelines have always kind of straddled the line between being abstract, and documenting oddities in our tooling to explain why we have to do some bizarre things. 17:02:16 Ok, is there anything else anyone wants to bring up this week? 17:02:27 FWI: A quick count (still counting) tells, in F22 there already are > 25 Recommends and > 7 Suggests. 17:02:27 Can we just do the R thing? 17:02:42 tibbs: I meant for this ticket :) 17:02:52 Ah. 17:03:37 * tomspur likes to favor enhances over supplements 17:04:05 Yeah, the reverse dependencies thing probably needs some discussion too. 17:04:09 tomspur: that's the reverse recommends, over info-reocmmends? 17:04:32 geppetto: yes Supplements is the reverse Recommends 17:04:39 I like them because I can add a package A that enhances some other package B without having to mess with B at all. 17:05:19 But I'd really hate it if I were the maintainer of B and someone basically forced their package into my dependency list. 17:05:33 Maybe with a specific example I see the use case better. For now it just feels dangerous with random Supplements: bash 17:05:33 well, I have heard the very opposite opinion 17:05:37 So Enhances: good, Supplements: bad. 17:05:52 tibbs: that always felt wrong to me … I can see why it's a great hack for an add-on package you create and obviously can't change your vendor package 17:06:09 tibbs: But for the vendor itself, just change B … or not. 17:06:54 I might be able to come up with two variants of the policy one more reverse deps friendly and one more conservative 17:07:08 But I'm happy to leave all of that out of the draft, or to ban them altogether in Fedora. 17:07:27 I mean, in Fedora we don't have an upstream vendor who might not want to change anything. 17:07:35 EPEL can make their own rule if they want to do so. 17:07:57 ffesti: Why doesn't rpm have -q --whatrecommends etc. ? 17:08:00 Yeh, feel free to just concentrate on just "recommends" … when people can apply it, or change requires to it, and how users turn it off/on and what that means. 17:08:07 And of course you get into the question of whether someone can Enhances: a pacakge in rpmfusion or something. 17:08:14 We can then add more policy around reverse-deps later. 17:08:47 Well, if we're going to do anything with soft deps but leave off the reverse cases, we really should explicitly ban them. 17:09:14 jsilhan: Quick question … if you have recommends turned on … does it treat them as requires when doing clean_requirements_on_remove? 17:09:25 Because the whole "just throw random crap into your packages without guidelines" think is a recipe for disaster. 17:09:34 s/think/thing/. 17:09:44 geppetto, TBH I don't know -> will try 17:09:57 FYI: Counting just finished: 27 Recommends, 7 Suggests in fc22 17:10:13 racor: So no reverse deps? 17:10:14 racor: Any Enhances: or Supplements: 17:10:21 ? 17:12:00 racor, looks like that slipped through somehow. Will add it. 17:12:05 geppetto, tibbs: Not checked yet, I just started it. 17:12:23 ffesti: OK, glad to hear this. 17:12:50 Ok, let's move on then. 17:12:56 #topic #532 Guidelines Draft: Systemd Preset Policy 17:13:00 .fpc 532 17:13:01 geppetto: #532 (Guidelines Draft: Systemd Preset Policy) – fpc - https://fedorahosted.org/fpc/ticket/532 17:13:07 https://fedorahosted.org/fpc/ticket/532 17:14:49 I hadn't even seen this one yet. 17:15:15 yeh, it came in the last day or so 17:15:35 It seems fine, from what I can see 17:15:37 +1 17:15:42 The scriptlet snippet page is obvious to me. 17:15:48 +1 from me 17:15:57 Looks good +1 17:16:03 The starting services by default policy should move into the guidelines. 17:16:33 I think. Since it isn't there currently, I guess we don't care about changes made to it. 17:16:37 But +1 anyway. 17:17:09 +1 from me 17:17:49 racor: vote? 17:17:58 tomspur: vote? 17:18:12 and I agree with tibbs on the moving the policy into FPG 17:18:32 Do I see it right, that a service must meet all critera and not just one? 17:19:38 tomspur: no 17:19:42 I read the first one as being "here are the exceptions, everything else is banned" 17:19:52 Where each exception is self-contained 17:19:59 it's either local, non-persistent or is on the approved exceptions list 17:20:09 yeah... my mistake... 17:20:24 sorry, was reading +1 17:20:46 fstrim seems to be bad but would count as non-persistent service isn't it? 17:20:57 tomspur: yeh 17:21:17 what do you mean by bad? 17:21:38 geppetto, tibbs: FYI: There don't seem to be any Suggests and Enhances in fc22 17:21:48 I remember something about that on the fesco ticket discussion 17:21:49 racor: cool, thanks 17:22:27 Sorry folks, my time is up for today, I need to quit now. 17:22:33 racor: ok 17:22:46 geppetto: https://fedorahosted.org/fesco/ticket/1441#comment:4 17:23:51 tomspur: Well the policy does say "may be enabled by default (but is not required to do so)." 17:24:12 hopefully the fstrim packager wouldn't enable it, if it's dangerous 17:24:29 ok 17:24:31 +1 17:24:41 #action Updated systemd Preset Policy #532 (+1:7, 0:0, -1:0) 17:25:06 #topic #535 Adjust the place of DESCRIPTION in R packaging guidelines 17:25:09 .fpc 535 17:25:12 geppetto: #535 (Adjust the place of DESCRIPTION in R packaging guidelines) – fpc - https://fedorahosted.org/fpc/ticket/535 17:25:14 https://fedorahosted.org/fpc/ticket/535 17:25:57 seems like a trivial +1 17:26:08 yes, +1 17:26:27 +1 17:26:53 +1 17:26:57 +1 17:27:16 we should also note why 17:28:06 not sure we really need to say "because DECRIPTION files aren't really docs" 17:28:33 +1 17:28:41 I can say why in the announcement, but I agree that it really doesn't need to be in the guidelines. 17:29:00 * geppetto nods 17:29:12 #action Adjust the place of DESCRIPTION in R packaging guidelines (+1:6, 0:0, -1:0) 17:29:50 #topic Open Floor 17:30:18 None of the older tickets seem to have changed in the last week … but does anyone want to talk about them? 17:31:08 I have problems with testing the macros in #281. Does someone see what is wrong in that macro? (see last comment over there) 17:31:35 ffesti: you still around? 17:31:56 I've been terrible about doing announcements but I'm on vacation today so I'm going to finish all of the pending writeups and announcements today. 17:32:36 I also wanted to point out https://github.com/fedora-python/packaging-guidelines/ 17:32:55 tomspur: Did you mean to define py_rt_build twice? 17:33:07 rkuska was trying to get together a collaborative guideline effort, but I'm not entirely sure that github is a good way to do wiki pages. 17:34:09 geppetto: hmm, I don't think so. Shouldn't the last one be used anyway 17:34:21 tomspur: I've no idea 17:34:37 I will delete the first py_rt_build and try again 17:35:26 my time is up as well 17:35:29 thanks everyone 17:35:32 In general terms, I think the python guidelines are the worst we have going currently, and I'm going to propose a crap-ectomy soon. 17:36:00 But that's just removing a bunch of admons and useless stuff so we can get down to actually simplifying the meat. 17:36:09 Rathann: see ya 17:36:12 tibbs: There are many python changes coming up. I don't know if those can be done easier step wise or with one big change of everything 17:36:21 I think one by one is far easier. 17:36:23 tibbs: I mean, that's all to do with py2 + py3, right? 17:36:38 tibbs: once we get rid of that disaster, it should be fine again … right? 17:36:48 tibbs: Each change would touch a lot of current packages in a row 17:37:06 I don't know if we have the manpower to do so 17:38:18 Well, changes to the guidelines don't really have to result in changes to packages. 17:38:28 I mean, our guidelines aren't retroactive anyway. 17:39:59 I don't think the py2->py3 transition can be done without that 17:40:54 I don't really see why not, but I think what matters is what changes are actually proposed. 17:41:44 If someone proposes a "tweak this bit" change like I did with my proposal last week then I guess we'd consider that. 17:42:04 I just don't see anyone actually making a concrete proposal for a rewrite. 17:43:48 I try to work on it with rkuska until the next meeting 17:44:45 ok 17:45:02 anything else? 17:46:12 Ok, see you all next week 17:46:20 #endmeeting