15:02:08 <spot> #startmeeting Fedora Packaging Committee
15:02:08 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:12 <spot> #meetingname fpc
15:02:12 <zodbot> The meeting name has been set to 'fpc'
15:02:23 <spot> #topic Roll Call
15:02:23 * geppetto is here
15:02:39 <spot> abadger1999 said he might be late this morning
15:02:57 <tibbs|h> Howdy.
15:04:11 <spot> Smoother1rOgZ, rdieter: ping?
15:04:23 <rdieter> hola
15:05:01 * abadger1999 now here
15:06:14 <spot> okay, that's quorum
15:06:40 <spot> #topic Devel Packages Clarification - https://fedorahosted.org/fpc/ticket/108 - https://fedoraproject.org/wiki/Devel_Packages%28draft%29
15:07:25 <spot> 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 <abadger1999> So... mschwendt still doesn't think this is sufficient :-(
15:07:46 <spot> what other case is he concerned about?
15:08:15 <tibbs|h> I'm afraid I've not understood what's wrong with the original guideline.
15:08:18 <geppetto> The only problem I can think of is "nss" … but they already dtrt, and nobody should be copying them
15:08:47 <tibbs|h> I applied the existing guideline for a large number of package reviews and never found any real issue with it.
15:08:59 <abadger1999> http://lists.fedoraproject.org/pipermail/packaging/2011-October/007944.html
15:09:28 <geppetto> 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 <limburgher> what'd I miss?
15:11:03 <spot> limburgher: we're discussing $TOPIC
15:11:29 <spot> limburgher: and apparently, the draft is not acceptable to mschwendt (who raised the initial concern)
15:11:36 <spot> http://lists.fedoraproject.org/pipermail/packaging/2011-October/007944.html
15:11:45 <rdieter> meh, the draft is certainly an improvement
15:11:51 <tibbs|h> I don't agree.
15:11:53 <limburgher> po que?
15:11:54 <limburgher> r
15:12:02 <spot> rdieter: yeah, i'm inclined to agree with you
15:12:04 <tibbs|h> I mean, adding complexity but still not getting it right is a problem.
15:12:22 <spot> i don't see where the draft gets anything wrong
15:12:23 <abadger1999> <nod>
15:12:33 <tibbs|h> And to be honest, this issue generally ends up coming down to a judgement call anyway.
15:13:09 <spot> the only thought I have here is that it may make more sense to explain this with an example
15:13:38 <abadger1999> 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 <tibbs|h> Not really.
15:13:54 <Rathann> sorry I'm late - making dinner
15:14:03 <tibbs|h> I mean, there are plenty of packages that necessarily violate it.
15:14:12 <tibbs|h> Like, say, compilers.
15:21:14 <tibbs|h> So...
15:21:56 <limburgher> racor:  So maybe something "if it's a building block of other software, it's for -devel"
15:21:58 <limburgher> ?
15:22:35 <tibbs|h> 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 <Rathann> 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 <limburgher> tibbs|h: <snicker>
15:23:26 <tibbs|h> 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 <tibbs|h> Does the current draft at least cover the issues where there has been confusion?
15:24:31 <geppetto> Why don't we just vote on abadger1999's changes … and then michael can ask for more changes if he wants?
15:24:48 <racor> limburgher: I am not sure, I don't have a good definition, either.
15:26:11 <tibbs|h> 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 <spot> i think i might be able to write a more comprehensive draft here with examples
15:26:50 <abadger1999> <nod>
15:26:54 <spot> it will almost certainly be longer though
15:27:12 <limburgher> It might be worth it.
15:27:27 <tibbs|h> The problem isn't length, I think.  It's "longer but still doesn't answer the question" that's problematic.
15:27:28 <abadger1999> 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 <spot> 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 <abadger1999> +1
15:28:12 <tibbs|h> Sure, let's have a look.
15:29:04 <spot> i'm not sure there are any other tickets ready for us to discuss
15:29:29 <spot> so...
15:29:32 <spot> #topic Open Floor
15:29:39 <racor> spot: how about the binutils exception?
15:30:07 <spot> 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 <tibbs|h> I assume that some packages would have to add dependencies on the stuff that's split out.
15:31:32 <spot> the request was to "remove them altogether"
15:31:36 <racor> i am not aware of any package in Fedora which uses these libs.
15:32:07 <racor> gdb is statically linked against private libbfd ibopcodes
15:32:09 <tibbs|h> Oh, I read it as "remove them from binutils" and assumed that meant sticking them in separate package.
15:32:56 <tibbs|h> Why would someone have to ask us if they want to drop unneeded stuff from their package?
15:34:09 <spot> repoquery says nothing besides binutils is using them
15:34:32 <racor> Fedora has shipped them, so there might be people using them, ... outside of Fedora.
15:35:02 <spot> 702648 implies that "insight" wants to use them instead of their own bundled copies
15:36:20 <rdieter> kdesdk/kmtrace uses libiberty
15:36:24 <spot> so, i suppose the question is whether an "unstable ABI" is sufficient grounds to permit bundling of a library
15:36:42 <spot> rdieter: i think the only two libs being discussed here are bfd and opcodes
15:36:49 <rdieter> oh, ok
15:37:34 <spot> in this specific case, as racor points out, gdb is bundling copies of these items already
15:37:58 <abadger1999> I don't think unstable ABI is sufficient.
15:38:47 <abadger1999> 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 <spot> 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 <spot> looking quickly at gdb
15:40:39 <spot> the bundled copy of bfd is kept synced with current binutils
15:40:49 <racor> rdieter: are these k* progs expecting external versions?
15:40:53 <spot> the same is true with opcodes
15:41:15 <racor> spot: not quite. They are "sort of synced". De-facto they diverge.
15:41:17 <spot> but i have no idea whether there is a history of pain there as binutils diverges/breaks ABI
15:41:26 <abadger1999> heh.  Also: https://fedorahosted.org/fpc/ticket/43
15:41:58 <rdieter> 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 <spot> this is lower level than i am familiar with
15:43:56 <abadger1999> Also: https://fedorahosted.org/fpc/ticket/63
15:43:58 <spot> my instinct would be to simply add bfd, cpu, opcodes to the exceptions list.
15:45:00 <spot> using the same logic as libiberty
15:45:57 <rdieter> spot: me too
15:46:18 <abadger1999> "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 <abadger1999> spot: Do you have a link to the libiberty decision?
15:46:37 <spot> 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 <spot> https://fedorahosted.org/fesco/ticket/370
15:47:38 <tibbs|h> Ugh.
15:47:39 <racor> spot: please exclude libiberty
15:48:00 <spot> racor: libiberty is already on the exceptions list
15:48:11 <racor> binutils by default installs/provides libiberty, but does not install libbfd, etc.
15:48:33 <spot> [spot@pterodactyl opcodes]$ rpm -ql binutils |grep bfd
15:48:34 <spot> /usr/bin/ld.bfd
15:48:34 <spot> /usr/lib64/libbfd-2.21.53.0.1-2.fc16.so
15:48:41 <spot> racor: you were saying?
15:49:10 <racor> spot: must be RH specific. FSF-binutils doesn't do so.
15:49:30 <racor> (Note to myself: Verfy)
15:49:36 <spot> 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 <abadger1999> *sigh*
15:53:18 <abadger1999> 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 <spot> 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 <racor> 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 <abadger1999> spot: Err... that would be in direct conflict with them wanting people to bundle.
15:54:45 <abadger1999> spot: A bundle is essentially a static link of a random version in time
15:54:51 <spot> abadger1999: no, they want people to pick the ABI that works for them and bundle _that_
15:55:20 <abadger1999> 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 <spot> abadger1999: *nod*
15:55:31 <abadger1999> spot: Which is... a random version in time, yes?
15:55:37 <spot> abadger1999: well, its not random.
15:55:42 <spot> its a chosen point in time.
15:56:00 <spot> as opposed to requiring that they link to the static lib in binutils-static at build time
15:56:03 <abadger1999> Okay...  Sure.  But it's not a point chosen via a collaboration with other projects
15:56:06 <spot> which is random
15:56:15 <spot> abadger1999: agreed
15:56:32 <abadger1999> So for us, as system integrators, its random.
15:56:35 <spot> at least in gdb's case there seems to be some collaboration
15:56:38 <jsmith> Random is in the eye of the beholder?
15:56:39 <limburgher> spot: One hopes that the choise of point in time is for a reason, but that isn't always so.
15:56:46 <limburgher> choice
15:57:03 <racor> 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 <spot> 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 <racor> so, if you want to be nitpicking it is sort of "random snapshot"
15:57:50 <spot> spec also includes lines like this:
15:57:55 <spot> # Prevent programs from linking against libbfd and libopcodes
15:57:55 <spot> # dynamically, as they are change far too often.
15:57:55 <spot> rm -f %{buildroot}%{_libdir}/lib{bfd,opcodes}.so
15:57:56 <abadger1999> racor: Okay... so once you get projects outside of gnu wanting to use that code, what should happen
15:58:24 <abadger1999> It sounds like we really need a separately packaged libiberty/bfd/opcodes
15:58:31 <abadger1999> 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 <abadger1999> and the gnu apps are allowed to consider those as copylibs.
15:59:03 <racor> abadger1999: this thought is naive dreamery.
15:59:18 <abadger1999> well... the benefit and drawback is the same as for any bundled library
15:59:21 <MarkDude> Beefy Miracle in Blacksburg- yay!
16:00:19 <racor> abadger1999: I wish you luck ...
16:00:37 <limburgher> 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 <abadger1999> 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 <spot> well, we're out of time for today
16:01:03 <spot> we'll revisit this next week
16:01:05 <spot> thanks everyone.
16:01:08 <spot> #endmeeting