17:01:36 #startmeeting fpc 17:01:36 Meeting started Thu Jan 27 17:01:36 2022 UTC. 17:01:36 This meeting is logged and archived in a public location. 17:01:36 The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 17:01:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:36 The meeting name has been set to 'fpc' 17:01:37 #meetingname fpc 17:01:37 #topic Roll Call 17:01:37 The meeting name has been set to 'fpc' 17:01:50 * GwynCieslasheher here 17:02:06 .hi 17:02:07 carlwgeorge: carlwgeorge 'Carl George' 17:02:10 #chair GwynCieslasheher 17:02:10 Current chairs: GwynCieslasheher geppetto 17:02:15 #chair carlwgeorge 17:02:15 Current chairs: GwynCieslasheher carlwgeorge geppetto 17:03:15 Hey. 17:04:05 #chair tibbs 17:04:05 Current chairs: GwynCieslasheher carlwgeorge geppetto tibbs 17:04:23 .hello2 17:04:24 decathorpe: decathorpe 'Fabio Valentini' 17:06:19 #chair decathorpe 17:06:19 Current chairs: GwynCieslasheher carlwgeorge decathorpe geppetto tibbs 17:11:27 #topic Schedule 17:11:30 #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/QFDIKXHIYBBA5UI7JT5SPVZILD2CXMRA/ 17:12:00 #topic #pr-1152 Add BLAS/LAPACK guidelines 17:12:00 https://pagure.io/packaging-committee/pull-request/1152 17:12:26 There are a lot of +1's here already 17:12:47 I missed t, I'll +1 there 17:13:07 I think we can just merge it now, unless anyone has any objections or requested changes? 17:13:13 Ship it 17:13:54 Ok, I pressed the button 17:14:03 yeah I don't think I plussed it yet, but it makes sense to have guidelines for this 17:14:39 Agreed, it' sone of those things that seem to come up every few years and it's important to do it right and consistently across the board as much as possible. 17:14:58 #topic #1150 request for clarification wrt. base version / compat package naming 17:14:59 .fpc 1150 17:14:59 https://pagure.io/packaging-committee/issue/1150 17:15:00 geppetto: Issue #1150: request for clarification wrt. base version / compat package naming - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1150 17:15:19 Linear Algebra: It's Everybody's Problem. 17:16:05 We talked about this last week, but had a couple of comments 17:16:26 I think the golang problem could be fixed by just changing the macros 17:16:41 Although migration will be a problem, I guess 17:17:02 geppetto: not really, as upstreams are identified by those paths anyway 17:17:50 i.e. something like "use github.com/foo/bar/v2" or something like that ... I don't think it would make sense to break expectations by doing this differently on the RPM side for no good reason 17:18:22 meant to reply to this one, but my response the to "but what about libsoup3 on a stable branch" is that should be discouraged by way of it being annoying/difficult (but not impossible) 17:18:30 eh, I'm not sure we need to keep the devel github urls in sync. with rpm package names 17:19:13 but the github URLs are how the project is identified 17:19:20 there's literally no other way to do that 17:20:52 decathorpe: Yeh, I'm just not sure that needs to leak into Fedora package names 17:21:33 decathorpe: I'd assume most golang devs. could work out what syncthing1 and syncthing2 mean. 17:22:28 But then the opinion from last week was that it would be a difficult project to unify this across the distro. … so ¯\_(ツ)_/¯ 17:22:45 yeah, I don't think there's a one-size-fits-all solution here 17:23:21 Ultimately different upstreams do different things, so all we can really attempt is to acheive as much consistency as possible while not concentrating the pain all in one spot. 17:23:35 s/acheive/achieve/ 17:24:55 i before e, except when not ;) 17:24:57 I think something like this would make sense: "In general, the package without the version suffix SHOULD be the one with the latest version. If there are more specific naming guidelines for your language or ecosystem, apply those instead." 17:25:32 Fabio Valentini That could work. 17:25:52 geppetto English is the best language, exect for all the others. 17:26:05 s/exect/except/ 17:26:10 In the end it has to be up to the packager, but it doesn't hurt to state that at least the common case is unversioned = "latest". 17:26:22 * geppetto nods 17:26:31 Of course, "latest" doesn't usually mean "git head". 17:26:35 yep 17:26:38 decathorpe: You want to propose an MR with that somewhere? 17:26:52 latest released? 17:27:04 latest packaged? 17:27:43 I can try to add something like that to the guidelines .. though I'm not sure where would be the best place for it. 17:27:44 packaged seems like a confusing thing to say in this context 17:28:02 If I want to package the latest stable release and a development build, I'd make the unersioned one the stable version. 17:28:29 latest upstream version/snapshot 17:28:44 I was thnking so. Maybe released, it's not like we're going to have libsoup3 and libsoup both following git HEADs....I hope,.... 17:28:47 tibbs: See, this is where things are getting complicated again :) 17:29:16 That's precisely why this is left out of the current guidelines. 17:29:32 It's ultimately up to the packager. 17:29:48 Maybe. We won't hit perfect but we can have least worst. 17:30:33 Yeh, I think we are aiming for "If you aren't sure what to do, try this." and less "This is what you should do." 17:30:58 So something will hopefully be better than nothing 17:31:05 instead of just have several apparently equal SHOULDs, can we phrase it to prioritize them? 17:31:23 "this way will hurt least" 17:36:03 I can make a flowchart :) 17:37:24 decathorpe++ 17:37:24 geppetto: Karma for decathorpe changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:37:41 Maybe a couple of examples will be better than a paragraph of text? 17:37:54 But I'm +1 on a flowchart 17:38:22 Me too 17:38:41 (flowchart was supposed to be a joke, but if you want one ...) 17:39:13 decathorpe: I know :) 17:39:23 seems there is still some lag on the matrix/irc bridge 17:39:24 instead of just have several apparently equal SHOULDs, can we phrase it to prioritize them? 17:39:25 I was more thinking along the lines of "here's a list of things to consider, and if any of those match, you know what to do" 17:40:06 decathorpe: yeh, seems good 17:40:20 coincidentally I think the way we name compat packages is broken, but I don't want to open that particular can of worms yet ... 17:40:31 I'll try to work out something. 17:40:34 carlwgeorge[m]: I saw that … I'm less sure how to prioritize 17:40:56 #action decathorpe will solve everything. 17:41:10 #topic Open Floor 17:41:49 Nothing else, tagged as meeting, is new or has changed since last week 17:41:50 geppetto: That's a tall order, but I'll manage. 17:42:03 So … anything anyone wants to talk about? 17:42:35 Not me. 17:42:47 How about just saying we leave it to the packager's best judgement but if the best option isn't clear, then do X. 17:43:01 decathorpe: I've got my official "solved" stamp ready, whatever you do will get stamped ;) 17:43:04 i had one 17:43:14 carlwgeorge: Go for it 17:43:15 Sorry I'm slow. 17:43:27 i thought this was already covered in guidelines, but i can only find it for libraries https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_explicit_lists 17:43:50 "don't over-glob", e.g. `%{_bindir}/*` 17:44:11 anyone have thoughts on that before i submit a pr to make that generic, vs just for libs? 17:44:58 I would generally be against doing anything other than suggesting that packagers be careful with globbing. 17:44:59 No. 17:44:59 ah, wrong link https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files 17:45:22 The library thing is due to that being a constant source of breakage. 17:45:26 the python link is the example i want to follow 17:45:28 I think that's a good rule of thumb. Don't use globs for anything where it can cause problems if packages add or remove stuff. 17:45:37 > Packagers SHOULD NOT simply glob everything under a shared directory. 17:45:41 Is there a constant source of breakage due to new binaries appearing? 17:46:10 my point is this is already in the python guidelines, but i would like to make it generic for all packages 17:46:30 This makes packaging more complex in some cases so it would need to have an actually perceptible gain instead of just making people list more things in %files. 17:47:00 carlwgeorge: How do you want to make it more generic? 17:47:12 tibbs: I know literally zero packages which use globs like this correctly. 17:47:26 copy the python guideline on this topic and put it in the main guidelines, removing the python specific examples 17:47:27 Like the shared lib. thing is w/e … but it's common to do the same looking thing for man pages. 17:47:31 so I'm all for saying "don't do that" 17:47:57 tibbs: it prevents new upstream commands that conflict with other packages being shipped unknowingly 17:48:02 I guess it depends on how you define "correctly". 17:48:43 And how often does that happen in practice, as opposed to the library thing which caused unknown ABI bumps all the time? 17:49:16 would you consider using "*" as the only thing in %files a good thing? because that's the next step down the slippery slope of "how often can this cause new problems" :) 17:49:39 (I've seen packagers do that, btw.) 17:49:48 That generally runs afoul of rules on directory ownership. 17:50:12 decathorpe: To be fair I sympathize, and kind of wish we could fix it so that would work. 17:50:18 well who's checking that outside of fedora-review? nobody ... 17:50:38 Eg. have rpm know that random packages shouldn't own /usr/bin or whatever 17:51:36 I have no problem having carlwgeorge make more generic "don't use globs in these cases, because it cases problems" … but less so if it's just more pain for possible problems. 17:52:53 and like the python one, it'll be a SHOULD NOT, so packages can say "i know better in this case" as needed 17:53:05 Personally I much prefer globs over having %if blocks in the %files list. 17:53:16 * geppetto nods 17:53:42 I'm probably fine with what you want to propose, I'm just old grumpy and like globs ;) 17:53:57 i'll work up a pr and wait for comments 17:54:02 * geppetto nods 17:55:13 Anything else anyone wants to talk about? 17:56:01 Not I said the duck. 17:57:11 Ok, see you next week. 17:57:15 #endmeeting