15:02:08 #startmeeting Fedora Packaging Committee 15:02:08 Meeting started Wed Oct 12 15:02:08 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:12 #meetingname fpc 15:02:12 The meeting name has been set to 'fpc' 15:02:23 #topic Roll Call 15:02:23 * geppetto is here 15:02:39 abadger1999 said he might be late this morning 15:02:57 Howdy. 15:04:11 Smoother1rOgZ, rdieter: ping? 15:04:23 hola 15:05:01 * abadger1999 now here 15:06:14 okay, that's quorum 15:06:40 #topic Devel Packages Clarification - https://fedorahosted.org/fpc/ticket/108 - https://fedoraproject.org/wiki/Devel_Packages%28draft%29 15:07:25 This seems fine to me. I'm a little concerned that this clarification is needed, but I have no issue with it at all. 15:07:35 So... mschwendt still doesn't think this is sufficient :-( 15:07:46 what other case is he concerned about? 15:08:15 I'm afraid I've not understood what's wrong with the original guideline. 15:08:18 The only problem I can think of is "nss" … but they already dtrt, and nobody should be copying them 15:08:47 I applied the existing guideline for a large number of package reviews and never found any real issue with it. 15:08:59 http://lists.fedoraproject.org/pipermail/packaging/2011-October/007944.html 15:09:28 abadger1999: Myabe change the last line to: "A good rule of thumb is if the file is used for BuildRequires and not Requires, it should go in -devel. 15:10:30 * limburgher here 15:10:53 what'd I miss? 15:11:03 limburgher: we're discussing $TOPIC 15:11:29 limburgher: and apparently, the draft is not acceptable to mschwendt (who raised the initial concern) 15:11:36 http://lists.fedoraproject.org/pipermail/packaging/2011-October/007944.html 15:11:45 meh, the draft is certainly an improvement 15:11:51 I don't agree. 15:11:53 po que? 15:11:54 r 15:12:02 rdieter: yeah, i'm inclined to agree with you 15:12:04 I mean, adding complexity but still not getting it right is a problem. 15:12:22 i don't see where the draft gets anything wrong 15:12:23 15:12:33 And to be honest, this issue generally ends up coming down to a judgement call anyway. 15:13:09 the only thought I have here is that it may make more sense to explain this with an example 15:13:38 tibbs|h: Hmm... I agree with complexity but I'm not sure about characterizing it as a judgement call -- isn't the build-time/runtime distinction pretty cut and dried? 15:13:50 Not really. 15:13:54 sorry I'm late - making dinner 15:14:03 I mean, there are plenty of packages that necessarily violate it. 15:14:12 Like, say, compilers. 15:21:14 So... 15:21:56 racor: So maybe something "if it's a building block of other software, it's for -devel" 15:21:58 ? 15:22:35 I'm afraid there simply isn't a general rule. It's always been "I know -devel material when I see it." 15:22:42 compilers I think should be mentioned as an exception, even though their "devel" files do fall into "needed for base package operation" category 15:22:50 tibbs|h: 15:23:26 I guess I can concede that the existing guideline may be too sparse for some to interpret the way we'd hope. 15:24:29 Does the current draft at least cover the issues where there has been confusion? 15:24:31 Why don't we just vote on abadger1999's changes … and then michael can ask for more changes if he wants? 15:24:48 limburgher: I am not sure, I don't have a good definition, either. 15:26:11 Why don't we just state up front, in the guideline, that the question of what's -devel and what's not is difficult to answer, so people don't think they're running down a checklist that is supposed to tell them exactly what to do? 15:26:42 i think i might be able to write a more comprehensive draft here with examples 15:26:50 15:26:54 it will almost certainly be longer though 15:27:12 It might be worth it. 15:27:27 The problem isn't length, I think. It's "longer but still doesn't answer the question" that's problematic. 15:27:28 When I was writing this, I wa reasonably satisfied with the longer portion in the Guiedlines proper but somewhat dissatisfied with the succinct version for ReviewGuidelines. 15:27:33 if no one objects, i'd like to do that, and i'll update the ticket with it when it is done 15:27:50 +1 15:28:12 Sure, let's have a look. 15:29:04 i'm not sure there are any other tickets ready for us to discuss 15:29:29 so... 15:29:32 #topic Open Floor 15:29:39 spot: how about the binutils exception? 15:30:07 racor: i posted a comment to it this morning basically noting that it seems like removing those libraries will cause problems with dependent packages like gdb 15:30:38 I assume that some packages would have to add dependencies on the stuff that's split out. 15:31:32 the request was to "remove them altogether" 15:31:36 i am not aware of any package in Fedora which uses these libs. 15:32:07 gdb is statically linked against private libbfd ibopcodes 15:32:09 Oh, I read it as "remove them from binutils" and assumed that meant sticking them in separate package. 15:32:56 Why would someone have to ask us if they want to drop unneeded stuff from their package? 15:34:09 repoquery says nothing besides binutils is using them 15:34:32 Fedora has shipped them, so there might be people using them, ... outside of Fedora. 15:35:02 702648 implies that "insight" wants to use them instead of their own bundled copies 15:36:20 kdesdk/kmtrace uses libiberty 15:36:24 so, i suppose the question is whether an "unstable ABI" is sufficient grounds to permit bundling of a library 15:36:42 rdieter: i think the only two libs being discussed here are bfd and opcodes 15:36:49 oh, ok 15:37:34 in this specific case, as racor points out, gdb is bundling copies of these items already 15:37:58 I don't think unstable ABI is sufficient. 15:38:47 However, I feel like this might be a copylib case... but it's not apparent from what the binutils maintainer has given us. 15:38:59 https://bugzilla.redhat.com/show_bug.cgi?id=702648 has a little more meat 15:39:32 * abadger1999 knows of plenty of python and php applications which would love to bundle if API stability was the sole criteria 15:40:22 looking quickly at gdb 15:40:39 the bundled copy of bfd is kept synced with current binutils 15:40:49 rdieter: are these k* progs expecting external versions? 15:40:53 the same is true with opcodes 15:41:15 spot: not quite. They are "sort of synced". De-facto they diverge. 15:41:17 but i have no idea whether there is a history of pain there as binutils diverges/breaks ABI 15:41:26 heh. Also: https://fedorahosted.org/fpc/ticket/43 15:41:58 racor: yes (libiberty is used solely for symbol demangling) 15:43:24 * spot is really not qualified to make this decision, to be honest. 15:43:31 this is lower level than i am familiar with 15:43:56 Also: https://fedorahosted.org/fpc/ticket/63 15:43:58 my instinct would be to simply add bfd, cpu, opcodes to the exceptions list. 15:45:00 using the same logic as libiberty 15:45:57 spot: me too 15:46:18 "upstream is treating this as the static-library equivalent of a copylib. ie: you aren't supposed to bundle, but you are supposed to link statically since the public ABI changes with every release. Only the binutils tools themselves are supposed to use the dynamic libraries." 15:46:27 spot: Do you have a link to the libiberty decision? 15:46:37 abadger1999: i think that was FESCo 15:46:42 * abadger1999 was really looking for that when he dug all these others up 15:46:50 https://fedorahosted.org/fesco/ticket/370 15:47:38 Ugh. 15:47:39 spot: please exclude libiberty 15:48:00 racor: libiberty is already on the exceptions list 15:48:11 binutils by default installs/provides libiberty, but does not install libbfd, etc. 15:48:33 [spot@pterodactyl opcodes]$ rpm -ql binutils |grep bfd 15:48:34 /usr/bin/ld.bfd 15:48:34 /usr/lib64/libbfd-2.21.53.0.1-2.fc16.so 15:48:41 racor: you were saying? 15:49:10 spot: must be RH specific. FSF-binutils doesn't do so. 15:49:30 (Note to myself: Verfy) 15:49:36 racor: that may be possible, but fedora's binutils package has had libbfd and libopcodes copies in that package for a while now 15:52:15 *sigh* 15:53:18 So reading the definition of copylibs that I wrote and the lack of documentation on why libiberty was considered a copylib by fesco... I'm not sure whether I'd consider it a copylib or simply a library that it makes sense to link to statically. 15:53:59 abadger1999: i don't think the binutils people want people statically linking against a random version of whatever was present at the time 15:54:00 spot: FWIW: None of my cross-binutils/gdb/gcc rpms contains special treatment for bfd/opcodes, but they contain special treatment to avoid installing a native libiberty. 15:54:23 spot: Err... that would be in direct conflict with them wanting people to bundle. 15:54:45 spot: A bundle is essentially a static link of a random version in time 15:54:51 abadger1999: no, they want people to pick the ABI that works for them and bundle _that_ 15:55:20 spot: With the added "bonus" that the bundling people may change the source in ways that make it hard to port later. 15:55:28 abadger1999: *nod* 15:55:31 spot: Which is... a random version in time, yes? 15:55:37 abadger1999: well, its not random. 15:55:42 its a chosen point in time. 15:56:00 as opposed to requiring that they link to the static lib in binutils-static at build time 15:56:03 Okay... Sure. But it's not a point chosen via a collaboration with other projects 15:56:06 which is random 15:56:15 abadger1999: agreed 15:56:32 So for us, as system integrators, its random. 15:56:35 at least in gdb's case there seems to be some collaboration 15:56:38 Random is in the eye of the beholder? 15:56:39 spot: One hopes that the choise of point in time is for a reason, but that isn't always so. 15:56:46 choice 15:57:03 abadger1999: each of binutils/gdb/gcc etc. share a common source tree. As their releases are not sync'ed they each pick up the status at a point in time and test their works against this. 15:57:22 racor: looking at the fedora binutils spec, it looks like the generation of the libbfd-%{version}.so is coming from the code itself, not any custom spec magic 15:57:29 so, if you want to be nitpicking it is sort of "random snapshot" 15:57:50 spec also includes lines like this: 15:57:55 # Prevent programs from linking against libbfd and libopcodes 15:57:55 # dynamically, as they are change far too often. 15:57:55 rm -f %{buildroot}%{_libdir}/lib{bfd,opcodes}.so 15:57:56 racor: Okay... so once you get projects outside of gnu wanting to use that code, what should happen 15:58:24 It sounds like we really need a separately packaged libiberty/bfd/opcodes 15:58:31 that external-to-gnu applications target. 15:58:50 * spot has the sinking suspicion that we're just opening an unpleasant can of worms without any real benefit 15:58:51 and the gnu apps are allowed to consider those as copylibs. 15:59:03 abadger1999: this thought is naive dreamery. 15:59:18 well... the benefit and drawback is the same as for any bundled library 15:59:21 Beefy Miracle in Blacksburg- yay! 16:00:19 abadger1999: I wish you luck ... 16:00:37 I would imagine that the drawback of bundling for something this low-level would be even greater than normal, but I'm even less qualified than spot to make the call. 16:00:43 racor: I'm not saying that this is easy (or even easy enough to implement); I am saying if you want to bundle these libraries, then we have to justify it... and the current copylibs exception does not seem to be broad enoguh to cover it. 16:00:59 well, we're out of time for today 16:01:03 we'll revisit this next week 16:01:05 thanks everyone. 16:01:08 #endmeeting