16:00:22 <geppetto> #startmeeting fpc
16:00:22 <zodbot> Meeting started Thu Aug 20 16:00:22 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:22 <geppetto> #meetingname fpc
16:00:22 <geppetto> #topic Roll Call
16:00:22 <zodbot> The meeting name has been set to 'fpc'
16:00:41 <geppetto> geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ tibbs|w tomspur: FPC ping
16:00:45 <orionp> Morning
16:00:47 <tibbs|w> Howdy.
16:00:49 <mbooth> Hi
16:00:54 <geppetto> #chair mbooth
16:00:54 <zodbot> Current chairs: geppetto mbooth
16:00:56 <geppetto> #chair orionp
16:00:56 <zodbot> Current chairs: geppetto mbooth orionp
16:00:57 <geppetto> #chair tibbs
16:00:57 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:01:07 <geppetto> Hey, everyone
16:01:17 <geppetto> tibbs: I thought you were still on holiday?
16:01:34 <tibbs|w> Just got back home late last night.
16:01:38 <geppetto> ahh
16:01:47 <tomspur> Hi
16:01:48 <geppetto> #chair racor
16:01:48 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs
16:01:51 <geppetto> #chair tomspur
16:01:51 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs tomspur
16:02:20 <tibbs|w> Not that I've had much time to prepare but I don't think we have that much in the way of new stuff.
16:02:50 <geppetto> 4 new tickets, although a few seem easy
16:02:54 <geppetto> and one older one
16:03:09 <geppetto> #topic Schedule
16:03:14 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-August/010939.html
16:03:32 <geppetto> orionp: You want to revisist 555 first?
16:03:40 <orionp> Sure
16:03:56 <tibbs|w> I suspect 555 will take a while.
16:04:14 <geppetto> #topic #555 Copylib bundling request: kwsys in castxml
16:04:17 <geppetto> .fpc 555
16:04:19 <zodbot> geppetto: #555 (Copylib bundling request: kwsys in castxml) – fpc - https://fedorahosted.org/fpc/ticket/555
16:04:23 <geppetto> https://fedorahosted.org/fpc/ticket/555
16:05:20 <tibbs|w> So I don't really know what to do here.
16:06:20 <tibbs|w> It looks like a bunch of code but I heard that not all of it is actually used.
16:06:21 <geppetto> So … in the examples I looked at it seemed like they bundled the entire library
16:06:51 <geppetto> Which isn't what orionp said
16:06:58 <mathstuf> geppetto: the entire source tree is subtree merged, but the projects select which source files to build
16:07:13 <geppetto> There also seemed to be at least a couple of "big" parts like regexp.
16:07:33 <geppetto> mathstuf: That is a special kind of genius
16:08:17 <Rathann> hi
16:08:28 <geppetto> If the bigger scarier parts got unbundled, and people rm'd the bits they didn't build … I'd be fairly happy to treat it the same as gnulib, I think.
16:08:33 <geppetto> #chair Rathann
16:08:33 <zodbot> Current chairs: Rathann geppetto mbooth orionp racor tibbs tomspur
16:10:42 <geppetto> Anyone else have any questions/concerns/opinions?
16:10:55 <geppetto> orionp: You want to just let everyone bundle it as is?
16:11:12 <Rathann> too big to fail? ;)
16:11:27 <orionp> The only other practical option then is to remove the users from Fedora
16:11:28 <geppetto> well cmake certainly is
16:11:46 <mathstuf> just not how kwsys is meant to be used
16:12:19 * Rathann has grown to dislike cmake recently
16:12:30 <geppetto> Yeh, but we can't not ship cmake
16:12:34 <mathstuf> its pretty much a compatibility layer to support many many platforms
16:12:47 <geppetto> … castxml isn't in the same league though
16:13:14 <mathstuf> while regex.h may be nice and modern, no one is going to port it to visual studio 7
16:13:31 <Rathann> I wish it were practical to package kwsys-source and have all consumers rm -rf their bundled copies and BuildRequire: kwsys-source
16:13:32 <mathstuf> geppetto: castxml is a new buildreq for InsightToolkit releases
16:13:45 <geppetto> What is that?
16:13:53 <Rathann> ITK
16:14:12 <geppetto> What is that?
16:14:16 <geppetto> :)
16:14:28 <mathstuf> ITK, medical imaging library
16:14:41 <geppetto> Might be better to just say how many users it has, how many will be affected if it doesn't get in
16:14:59 <mathstuf> anyone using gccxml now will have to port at some point
16:15:44 <mathstuf> unless someone ports it to 5.x (castxml is a pure replacement)
16:16:43 <orionp> One other user of InsightToolkit in Fedora - nifti2dicom
16:17:09 <mbooth> TBH, I would be happy to call this a copylib
16:17:31 <Rathann> well that's the current state of it
16:17:46 <Rathann> a bit similar to rawspeed
16:19:16 <orionp> mathspeed - would there be any willingness to produce proper libraries for at least some components of KWSys, e.g. the regex part?
16:19:24 <orionp> sorry, mathstuf
16:20:25 <tibbs|w> Is the regex part even used under linux?
16:20:37 * mbooth thought pcre could be built for windows (it is a pre-req for httpd after all)
16:20:45 <mathstuf> tibbs|w: yes, it has to be the same impl for windows and linux
16:20:46 <tibbs|w> It was mentioned that some of it compiled out completely.
16:20:54 <tibbs|w> "has to be"?
16:21:01 <mathstuf> for compatibility
16:21:10 <Rathann> platform abstraction layer
16:21:11 <tibbs|w> If you've done that you've failed already.
16:21:19 <tibbs|w> But we knew that anyway.
16:21:26 <mathstuf> you cant parse regexes one way on one platform and as another elsewhere
16:21:54 <tibbs|w> Which is why you port the _standard_ library to the platforms that don't have one.
16:22:05 <tibbs|w> Instead of writing your own random thing and using it everywhere.
16:22:15 <Rathann> yeah
16:22:17 <mathstuf> kwsys was started before regex.h was even thought of; might even be older than pcre
16:22:25 <tibbs|w> But it's not as if we didn't know this was a huge software engineering failure.
16:22:30 <mathstuf> its TI's standard embedded implementation
16:22:42 <Rathann> TI's?
16:22:56 <mathstuf> texas instruments
16:23:04 <mathstuf> released as public domain at some point (IIRC)
16:23:33 <mbooth> This is a bit off topic probably -- what's done is done ;-)
16:23:39 <Rathann> indeed
16:24:49 <Rathann> the basic quesion is: is kwsys going to be rewritten to be only a thin abstraction layer over standard libraries or is it going to keep reimplementing world+dog?
16:25:12 <geppetto> I'm looking again at:
16:25:16 <geppetto> https://github.com/CastXML/CastXML/tree/master/src/kwsys
16:25:41 <geppetto> And a bunch of the files are huge
16:26:01 <geppetto> Eg. https://github.com/CastXML/CastXML/blob/master/src/kwsys/SystemInformation.cxx
16:26:13 <geppetto> is 5374 lines
16:26:33 <mathstuf> Rathann: its as thin as it is going to get given cmake's target platforms (on the whole; some things can move out of kwsys, but theyll just go into cmake itself instead, not away)
16:27:17 <geppetto> … now is there anything security related in there? … maybe not, but I'm not dying to have 666 apps. all dump 20k+ of random unsynchronized upstream code into their package as a "portability" layer
16:27:25 <mathstuf> geppetto: not used in castxml, but its large due to the number of systems supported
16:27:50 <geppetto> mathstuf: So is it possible for castxml to remove the giant files they aren't even using?
16:28:15 <Rathann> it's just badly design, IMHO - see what FFmpeg is doing, for example - all per-os compatibility cruft is in their own separate directories
16:28:36 <geppetto> If they end up with a few hundred lines of obvious portability stuff … I'm going to +1 them bundling it without a second thought
16:29:19 <mathstuf> Rathann: be that as it may, the library is quite old and isnt likely to get a complete rewrite just for sorting functions into separate files
16:29:30 <Rathann> string handling is an obvious security risk
16:29:46 <Rathann> I'd sure hope it's not reimplemented STL/boost
16:29:48 <geppetto> yeh, but that is one of the smaller files
16:30:08 <geppetto> it's just a strcasecmp that always works in C locale
16:30:18 <Rathann> process handling is 87k
16:30:37 <geppetto> And is the kind of thing I'd mostly just +1 … but, yeh, some of the other stuff is huge
16:30:43 <mathstuf> Rathann: which is used in castxml
16:30:49 <geppetto> bonus
16:31:08 <mathstuf> geppetto: castxml could rm the files that arent used in %setup even if not upstream
16:31:27 <geppetto> mathstuf: You can see how bundling 87k is more than not ideal, right?
16:32:39 <mathstuf> if llvm had the ability to run a process and capture the output, kwsys wouldnt really be needed there
16:32:46 <mathstuf> brad looked at it and kwsys was easier
16:33:25 <mathstuf> i agree that the library is big and scary, but it is tested on dozens of platforms every night and doesnt change that often anyways
16:33:37 <Rathann> mathstuf: is there a list of supported platforms?
16:34:41 <mathstuf> everything cmake supports as a target at least
16:34:56 <mathstuf> which includes things like solaris hpux, aix, and other fun *nix systems
16:35:28 <mathstuf> it also knows about things like embedded rtos systems and hardware bits (systeminformation)
16:36:46 <racor> mathstuf: something I do not understand: To me, a portability layer implies a stable ABI. I.e. this stuff to reads as an ideal candidate for a lib and not for a copylib
16:37:28 <mathstuf> http://public.kitware.com/pipermail/cmake-developers/2015-August/026040.html
16:37:49 <geppetto> Right. We aren't arguing it isn't useful … but when you have 1000s of lines of code, it quickly moves from "we want to bundle like gnulib" to "we want to bundle glib"
16:38:16 <Rathann> mathstuf: ffmpeg builds and runs on Plan9 (in addition to those you mentioned and Windows)
16:38:27 <Rathann> and the compat stuff for all platforms is 196k
16:38:31 <tibbs|w> It's starting to look more like "we want to bundle an entire libc".
16:38:34 <geppetto> mathstuf: Yeh, but imagine if the glib developers said the same thing?
16:38:54 <geppetto> Do we just give everyone a pass for want to make their lives a little easier and everyone else's life a lot harder?
16:39:36 <Rathann> mathstuf: http://public.kitware.com/pipermail/cmake-developers/2015-August/026040.html is just bad excuses for a bad design
16:40:12 <Rathann> and no responsibility towards consumers, probably because initially all consumers were written by the same people
16:40:23 * geppetto shrugs … you could try to get castxml to rm the stuff they don't use … maybe that would make it small enough to get the +1
16:40:37 <orionp> castxml-0.1-8a08a44/CMakeLists.txt:set(KWSYS_USE_Process 1)
16:40:38 <orionp> castxml-0.1-8a08a44/CMakeLists.txt:set(KWSYS_USE_RegularExpression 1)
16:40:39 <orionp> castxml-0.1-8a08a44/CMakeLists.txt:set(KWSYS_USE_SystemTools 1)
16:41:00 <orionp> Seems to be what it uses.
16:41:01 <geppetto> But I'm not currently convinced that this should be a copylib or that castxml needs an exception due to a bunch of people using/needing it
16:41:24 <mathstuf> i know it isnt ideal, but this is the way kwsys works, good design or no
16:41:40 <orionp> If we do not give copylib (which is fine) we need to decide what happens to the other KWSys users in Fedora
16:41:55 <geppetto> systemtools is 5.2k lines
16:42:19 <geppetto> regexp is 1.2k lines
16:42:33 <mathstuf> systemtools is a class with lots of static methods for path manipulation and filesystem queries
16:42:47 <geppetto> and another 450 in header
16:42:52 <mathstuf> it probably only uses a few of the functions
16:43:04 <geppetto> Yeh, I understand
16:43:06 <mathstuf> those could probably be moved to castxml itself and then systemtools wouldnt be needed
16:43:10 <tibbs|w> So here's what would work for me: Packages remove the stuff they don't use. We logically break down kwsys into pieces and packages add Provides: bundled(kwsys-systemtools) or bundled(kwsys-regexp) as appropriate for the pieces they use.
16:43:56 <mathstuf> im fine with rm in %setup to ensure that stuff; id have to look at doing it in the main package
16:44:07 <mathstuf> might be possible with export-ignore in a .gitattributes file
16:44:17 <mathstuf> so it wouldnt show up in tarballs
16:44:32 <geppetto> rm in setup isn't ideal as you have to run prep to see what isn't really there
16:44:49 <geppetto> What is the problem with just rm'ing the files in git?
16:45:05 <tibbs|w> I don't particularly care if it shows up in tarballs as long as it doesn't show up in packages, although I'd think upstreams would _want_ to get rid of code they don't use.
16:45:09 <racor> mathstuf: You claim to provide a portability layer and at the same time tell you don't guarantee a stable API. To me that's selfcontradictory.
16:45:10 <mathstuf> it might make updating files via the merge more of a hassle; id have to check
16:45:49 <mathstuf> racor: because projects update it on their own time
16:45:58 <tibbs|w> I'd think there would be less to merge so less hassle.
16:46:06 <tibbs|w> But... software engineering.
16:46:24 <geppetto> tibbs: I assume that they have some automated script which just dumps new versions of everything in ?
16:46:26 <mathstuf> we certainly can look at getting the bits that only cmake uses into cmake itself
16:46:44 <mathstuf> that should make kwsys smaller (including systemtool methods only cmake uses)
16:46:54 <geppetto> mathstuf: Again, cmake isn't the real problem … although it would be nice if it was good … cmake obviously can't be removed
16:46:56 <tibbs|w> This is the kind of thing about which nobody cares _until_ there's some flaw in one of those modules, and then everyone wrings their hands about how bad the code is and how there isn't anything they can do to fix it.
16:47:09 <mathstuf> the STL compat stuff is also likely cmake-only (due to minimum requirements of compilers on the other projects)
16:47:18 <mathstuf> geppetto: it would make kwsys smaller, thats the point
16:48:25 <geppetto> I'm not sure I understand … my understanding was that kwsys was it's own project and castxml and cmake (among other things, I guess) both bundled it
16:48:38 <mathstuf> kwsys was refactored out of both, IIRC
16:48:41 <mathstuf> it was never standalone
16:48:42 <tibbs|w> Anyway, is there something upon which we can vote?
16:48:50 <geppetto> And, as said, we really can't do anything to cmake … way too much stuff needs it
16:49:00 <mathstuf> (first commit in 2003; way before my time)
16:49:09 <tibbs|w> We need to track things with Provides: bundled(whatever) regardless.
16:49:13 <mathstuf> agreed
16:49:27 <geppetto> So if upstream kwsys won't co-operate, then the main first thing to do is fix castxml
16:51:24 <tomspur> How about rm'ing in %prep, splitting of kwsys in logical parts like tibbs|w suggested and giving a temporal bundling exception so this can be revisited in 2 releases or so?
16:52:01 <mathstuf> i can look at adding export-ignore attributes so the unused bits don't appear in the source tarballs
16:52:02 <tibbs|w> +
16:52:04 <tibbs|w> +1
16:52:13 <tibbs|w> At this point any progress is progress.
16:52:27 <Rathann> if stuff that has just one consumer is moved into that one consumer, that'll make kwsys smaller
16:52:47 <tibbs|w> Right now everything that is bundling at least needs to add Provides: bundled(kwsys) pretty much immediately.
16:52:53 <Rathann> yes
16:53:08 <racor> tibbs|w:  To track we need some kind of version.
16:53:14 <tibbs|w> That can be made more finely defined once someone who knows this code can see how it could be logically broken down.
16:53:21 <Rathann> +1 to what tomspur proposed, it's definitely not ideal but at least it's progress
16:53:27 <geppetto> sure
16:53:35 <mathstuf> racor: the git logs mention the date and git hash of kwsys upon update
16:53:38 <tibbs|w> racor: At this point I'm not sure the source even has a version.
16:53:42 <tibbs|w> Does anyone know?
16:53:44 <mathstuf> i can look at having that info put into release notes
16:53:47 <Rathann> so git hash would be the "version"
16:53:52 <mathstuf> tibbs: date and hash
16:54:08 <geppetto> I'm not even sure that everyone always updates all the files at the same time
16:54:10 <tibbs|w> At least the date would be good.
16:54:15 <geppetto> So even the upstream git version isn't enough :(
16:54:28 <mathstuf> there are no tags in kwsys itself
16:54:46 <mathstuf> and no, cmake tends to update pretty much asap (as it is the main kwsys driver)
16:54:55 <mathstuf> vtk and itk probably are closer to "as needed"
16:54:59 <racor> tibb|w: Exactly, this stuff is playing nasty games, IMO. We can't even track the version to be able to check for vulnerabilities and bugs.
16:55:23 <tibbs|w> racor: I think we're all agreed that there's no real software engineering happening here.
16:55:58 <racor> mathstuf: the stuff in CopyXML seems be collected from different upstreams.
16:56:26 <mathstuf> i assume castxml, but what upstreams are you referring to?
16:57:00 <mathstuf> theres a repo on public.kitware.com and probably a mirror on github
16:57:35 <mathstuf> ah, no mirror on github, just forks others have pushed
16:57:45 <racor> Sorry, typo. I meant to says different versions/commits from upstream.
16:57:50 <racor> upstream: git://public.kitware.com/KWSys.git
16:58:38 <mathstuf> when a project updates, they usually grab master, whatever that happens to be
16:58:57 <racor> most of the stuff in copyxml seems 2 years old, and hasn't been sync'ed since then.
16:59:23 <mathstuf> i can ask brad about updating kwsys before releases at least
16:59:36 <mathstuf> that should help keeping it more up-to-date across the board
17:01:29 <Rathann> http://public.kitware.com/gitweb?p=KWSys.git
17:01:49 <Rathann> ah, racor posted it already
17:04:11 <geppetto> Ok, so I think we have 4 votes for tibbs/tomspur proposal
17:04:38 <orionp> I'm +1 (fairly obviously i think)
17:05:41 <geppetto> Which is basically: Add provides (with module naming); rm unused files in setup/prep; give tmp. exception.
17:05:59 <geppetto> I think that's +5 now … me; tibbs; tomspur; Rathann; orionp
17:06:12 <geppetto> Anyone else want to vote, anyone want to disagree with the +1?
17:06:27 <Rathann> not sure if the temp exception will do any good though
17:06:40 <Rathann> reading what Brad wrote
17:06:58 <mathstuf> id be ok with that (should give me enough time to slim kwsys down by functionality; unlikely enough for a file-per-platform kind of rearchitecthing though if thats possible/plausible)
17:07:30 <Rathann> oh, so you're going to work on it? great!
17:08:16 <geppetto> #action Allow 2 year tmp. exception for castxml after modularized provides are added, and rm of unused modules happens at prep or before ideally upstreeam git (+1:5, 0:0, -1:0)
17:08:22 <mathstuf> id likely be the one to do it anyways here :)
17:08:47 <geppetto> Ok, going to move on :)
17:09:19 <geppetto> I'll put the ticket in needinfo, and if you ping us when you've done the package changes it should be a simple pass
17:09:27 <geppetto> #topic #558 	Switch order of install macros
17:09:28 <geppetto> .fpc 558
17:09:28 <geppetto> https://fedorahosted.org/fpc/ticket/558
17:09:29 <zodbot> geppetto: #558 (Switch order of install macros) – fpc - https://fedorahosted.org/fpc/ticket/558
17:09:44 <racor> +1 with severe grim feeling in my guts.
17:10:12 <geppetto> this seems pretty trivial to me, but there's a lot of text in the ticket :-o. Can we all just +1 it?
17:10:24 <geppetto> racor: That was for 555?
17:10:49 <racor> for the tomspur prop on kwsys.
17:10:55 * geppetto nods
17:10:57 <racor> I was too slow ;)
17:11:12 <tibbs|w> geppetto: On 558, I think the guidelines are correct as is, but I could be missing something.
17:11:17 * geppetto nods … yeh, that's 555 … just making sure you weren't being super quick on 558 :)
17:12:20 <Rathann> I think comments 6 and 7 are a good summary
17:12:21 <geppetto> tibbs: I'm not sure, my understanding is that unversioned stuff should be py2, so the order should be reversed in the examples?
17:12:49 <Rathann> geppetto: yes, unless you're packaging an application that behaves the same under py3 and py2
17:12:50 <tomspur> +1
17:12:51 <geppetto> I agree … I'm just not sure if they agree that the order should be reversed or not
17:13:00 <Rathann> but in that case you don't build twice
17:13:10 <Rathann> so, in other words: yes
17:13:26 <tomspur> I think we should assume that the package behaves differently under py3 and py2 if there was a need to have both executables in the first place
17:13:33 <geppetto> right
17:13:59 <geppetto> that seems sane to me … if it works the same under both, you'd just ship one … right?
17:14:11 * tomspur hopes so
17:14:14 <geppetto> :)
17:14:15 <Rathann> yes
17:14:16 <Rathann> +1
17:14:35 <geppetto> I think that's +3 atm.
17:14:43 <geppetto> tibbs: racor: orionp: mbooth: vote?
17:14:45 <tibbs|w> So I think the issue here is really that the examples are confusing.
17:15:06 <orionp> I'm really not following yet
17:15:08 <racor> 0 ... I don't feel sufficiently competent on this matter
17:15:23 <tibbs|w> Because I was sort of hoping to avoid having a big pile of examples.  But I can write some...
17:15:39 <mbooth> tibbs|w: Maybe they can go on a separate page
17:15:46 <orionp> We're deciding whether apps have /usr/bin/python2 or /usr/bin/python3 by default?
17:16:04 <tomspur> orionp: If there are the binaries /usr/bin/pip /usr/bin/pip2 /usr/bin/pip3, the /usr/bin/pip must be the python2 implementation as /usr/bin/python is currently the python2 one
17:16:05 <tibbs|w> Right now, though, I don't think the order should be switched, because in general we want python3 to win in all places where it makes sense.
17:16:26 <tibbs|w> But this was one case where I was just working with the existing examples; I didn't really rewrite that.
17:16:39 <orionp> tomspur - ah, thanks
17:16:42 <tomspur> If there is just one /usr/bin/pip without the other pip2 and pip3, it must (or was it a should in the current guidelines?) be the python3 version
17:16:47 <racor> I am sorry, as usual around this time of day, I need to leave.
17:16:56 <tibbs|w> Wow, over an hour already.
17:17:08 <orionp> I'm +1
17:17:12 <tibbs|w> How about this: let me try and cook up some more examples.
17:17:51 <geppetto> tibbs: I'm happy with that, if you'd prefer
17:17:55 <tibbs|w> And make sure the module/application separation is clear.
17:18:19 <tibbs|w> But I can switch the order if people really want that.  It's just that it doesn't make sense to me because we do want py3 in preference to py2 in general.
17:18:32 <geppetto> Maybe
17:18:37 <tibbs|w> But again I note that this issue isn't new in the new guidelines.
17:18:46 * geppetto nods
17:19:00 <tomspur> As long as /usr/bin/python is python2 I expect to be /usr/bin/pip also the python2 version
17:19:03 <tibbs|w> It seems that because I changed something, people are taking a look at the guidelines again.
17:19:03 <geppetto> You want to do a bigger diff and talk about it next week then?
17:19:14 <geppetto> tibbs: very likely
17:19:25 <tibbs|w> tomspur: Yes, of course.  That's the case of an application with different functionality between python versions.
17:19:32 <tibbs|w> Which is... not what the example is about.
17:20:02 <tomspur> tibbs|w: I'd call the "application" a "module" then :)
17:20:21 <tomspur> It just happens to have a binary that imports the module
17:20:21 <geppetto> Ok, then … try to do an easy one and then we can get lunch :)
17:20:22 <tibbs|w> The vast majority of modules which happen to include an executable will be in the "doesn't care about python version" group.
17:20:34 * geppetto nods
17:20:43 <tibbs|w> And the point of the examples is to document the cases packagers will see most often.
17:21:15 <geppetto> #topic #559 	Ban use of rich dependencies
17:21:16 <geppetto> .fpc 559
17:21:16 <geppetto> https://fedorahosted.org/fpc/ticket/559
17:21:17 <zodbot> geppetto: #559 (Ban use of rich dependencies) – fpc - https://fedorahosted.org/fpc/ticket/559
17:21:28 <geppetto> This one came up at flock, and seems a pretty trivial +1
17:21:31 <tibbs|w> I was asked to do this by the DNF group manager at flock.
17:21:44 <tomspur> tibbs|w: So you prefer to have python3 isntalled by default _unless the binary behave differently under both implementations as an exception to that_?
17:22:13 <tibbs|w> tomspur: That's not just me.
17:22:21 <tibbs|w> That's the point of the whole "py3 as default" thing.
17:23:00 <tibbs|w> For rich dependencies, there is a syntax currently supported in RPM, and dnf actually supports them.
17:23:16 <tomspur> Yeah, sure. I think it's just easier to assume that if you have binaries for both implementations they always behave differently.
17:23:39 <tomspur> But the exception kind of thing more serves the py3 as default, so worth reconsidering next week...
17:24:14 <tibbs|w> People are welcome to experiment, but our buildsys tooling doesn't actually support rich deps so putting then in even a rawhide package would be bad.
17:24:27 <tibbs|w> Hence we need to make sure nobody actually tries to do that.  Plus the syntax isn't fixed.
17:24:41 <tibbs|w> Does everyone understand what rich deps are?
17:24:48 <orionp> +1 to banning
17:24:59 <tibbs|w> +1 from me obviously.
17:25:06 <tomspur> +1, sounds reasonable
17:25:34 <geppetto> Yeh, the big conserns atm. are: 1) syntax not finalized 2) Not much testing has happened, so nobody really knows what happens if they are used.
17:25:40 <geppetto> +1 banning
17:25:57 <geppetto> mbooth: vote?
17:26:04 <tomspur> What is the current syntax?
17:26:06 <geppetto> Rathann: vote?
17:26:18 <tomspur> R: (this OR that) like written in the ticket?
17:26:22 <geppetto> tomspur: AIUI there are 3 or 4 syntaxes that are supportly accepted
17:26:46 <geppetto> And they are going to pick one, and remove the others … to avoid confusion
17:26:55 <geppetto> But nobody has managed to pick one yet
17:26:57 * tomspur nods
17:28:49 <tibbs|w> I don't really care what they pick, but a few people promised to submit "OR" and "AND" packages if they pick the textual ones.
17:29:54 <Rathann> geppetto: +1 from me
17:30:11 <geppetto> mbooth: You want to vote for the record?
17:32:29 <geppetto> #action Ban use of rich dependencies (+1:5, 0:0, -1:0)
17:32:35 <geppetto> #topic Open Floor
17:33:00 <geppetto> Anyone want to bring anything up?
17:34:25 <tibbs|w> Nothing from me.  So much to do today....
17:34:30 * geppetto nods
17:34:44 <geppetto> I'll close in a minute, thanks for coming everyone
17:34:44 <tibbs|w> BTW, nice to actually meet you.
17:34:49 <orionp> I'm ready to be done...
17:34:58 <tibbs|w> Were there any other FPC folks at Flock who I didn't get to meet?
17:35:00 <geppetto> tibbs: Yeh, was cool :)
17:35:44 <geppetto> I hope not, would be annoying if we both missed them :)
17:35:48 <tibbs|w> I forgot to ask Xavier why he's unable to make FPC meetings.
17:36:22 * geppetto nods … IIRC from a long time ago he said it's a weird time for him now and he can't make it
17:36:53 <geppetto> But that was literally a couple of years
17:38:42 <tibbs|w> I'll ask him the next time I talk to him.  We like the same kind of music so he's started feeding me bands I should hear.
17:38:50 <geppetto> cool
17:39:00 <geppetto> Ok, going to close now … thanks for coming everyone!
17:39:04 <geppetto> #endmeeting