16:00:56 <spot> #startmeeting Fedora Packaging Committee
16:00:56 <zodbot> Meeting started Wed Oct 13 16:00:56 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:02 <spot> #topic Roll Call
16:01:06 <limburgher> Yeah.  The *one* day I don't brown-bag. :)
16:01:29 <Rathann> I'm here
16:01:30 * limburgher is here
16:01:45 * spot is here
16:02:26 <spot> abadger1999 rdieter tibbs SmootherFrOgZ: ping
16:02:35 * abadger1999 here
16:02:46 <rdieter> her
16:02:48 <rdieter> here even
16:03:23 <spot> well, thats 5 (quorum). I know tibbs was here earlier
16:03:29 <spot> racor may arrive a bit late
16:03:56 <spot> #topic D Guidelines - https://fedorahosted.org/fpc/ticket/7
16:04:05 <spot> https://fedoraproject.org/wiki/D%2Bpackaging%2Bguideline%2Bdraft
16:04:19 <spot> i finally got bioinfornatics to clarify the last issues
16:05:34 * spot will give everyone a moment to reread the draft
16:05:55 <Rathann> I hope the idea of moving to shared libraries as soon as upstream supports them is quite obvious and thus not written explicitly
16:06:24 <spot> Rathann: agreed
16:06:49 <spot> if there are no additional concerns, go ahead and toss out votes
16:06:51 <spot> +1
16:06:56 <Rathann> +1
16:07:08 <limburgher> +1
16:07:09 <abadger1999> +1
16:07:40 <spot> rdieter?
16:08:02 <rdieter> +1
16:08:20 <Rathann> hm, just noticed: what if the package contains not only static libs, but also binaries? one shouldn't disable debuginfo then
16:08:20 <spot> #action D draft is approved 5 +1, no 0, no -1
16:08:35 <Rathann> or?
16:08:41 <spot> Rathann: debuginfo doesn't know how to deal with static binaries
16:08:45 <Rathann> ah
16:08:55 <spot> loooong standing bug. :)
16:09:02 <Rathann> ok then
16:09:41 <spot> alrighty then
16:09:45 <spot> on to the "fun" stuff
16:09:56 <spot> #topic New library bundling exception - https://fedorahosted.org/fpc/ticket/15
16:10:39 <spot> so, the original request was to try to come up with a guideline that would cover the bundling in gupnp-dlna
16:11:10 <spot> but it morphed into a request for the fpc to handle bundling exceptions?
16:11:11 <spot> i think?
16:11:33 <abadger1999> Well...
16:11:54 <abadger1999> nirik asked whether we'd like to handle exceptions -- I don't think that was a request from fesco as a whole.
16:12:27 * nirik could ask at the next meeting if folks would like.
16:12:35 <spot> as much as i disagree with fesco's recent exceptions, i do think that it falls into their responsibilities
16:12:45 <abadger1999> the recent fesco has been a lot more lenient with exceptions than both previous fesco and we would be.... so it's causing conflicts.
16:12:46 <limburgher> Looks like an exception request situation, not a guideline issue.  FESCO fodder.
16:12:58 <limburgher> abadger1999 <nod>
16:13:12 * nirik notes elections will be coming up soon. :)
16:13:48 <spot> i think the only thing we could do would be to refuse to amend the guidelines to reflect the exceptions and ask the Board to reconsider.
16:14:10 <spot> but since i am on the board, i'd have to recuse myself from both proceedings
16:14:12 <abadger1999> Rationale for moving the responsibility to fpc would be that to remain fair we want to figure out why these exceptions should be granted and add the reasoning to the guidelines.  Lately, there doesn't seem to be a reason that can really be made from the exceptions granted.
16:14:34 <limburgher> nirik what, we should bum-rush them?
16:14:36 <limburgher> :)
16:14:40 <abadger1999> rationale for leaving with fesco -- if a maintainer conflicts with an fpc decision on granting an exception, it goes to fesco anyway.
16:15:01 <limburgher> abadger1999 <nod>
16:15:23 <spot> abadger1999: well, if fesco decides that they want us to handle the exceptions, we could certainly do so
16:15:30 <abadger1999> <nod>
16:15:39 <limburgher> Yeah.
16:15:43 <spot> nirik: please ask fesco about whether they want us to handle it or not
16:15:47 <nirik> ok.
16:15:48 <abadger1999> I would not be against us handling exceptions.
16:15:53 <Rathann> Agreed.
16:15:54 <spot> we'll wait to hear on that issue before we move forward on that ticket
16:16:13 <spot> #action nirik will ask FESCo if they want FPC to handle bundling exceptions
16:16:28 <spot> Alright. Moving on.
16:16:39 <spot> #topic Treatment of bundled libraries - https://fedorahosted.org/fpc/ticket/19
16:17:17 <spot> On this topic, I do not think it is necessary to remove bundled libraries from the tarball unless there is a legal reason (non-free, non-distributable)
16:17:33 <spot> I think deletion in %prep must be mandatory though.
16:17:42 <spot> and they should never end up in a package, even if they're unused
16:17:48 <Rathann> exactly
16:17:52 <rdieter> agreed
16:18:02 <limburgher> Emphatically yes.
16:18:42 <spot> the only corner case here is packages that bootstrap
16:19:06 <spot> and in those cases, they can use the bundled libraries to bootstrap, but still can't package them.
16:19:18 <limburgher> So we specify that.
16:19:27 * spot nods
16:19:31 <abadger1999> Note that deleting in %prep can cause more work patching the buildscripts.
16:19:54 <racor> spot: depends ... there are packages which are equipped with "bundled" libs, but explicitly support opts to use external ones (example: zlib/libz in GCC)
16:20:16 <Rathann> abadger1999: well, otherwise making sure that they are not used during compilation/linking can be a pain
16:20:16 * abadger1999 supposed autotools could work if we only delete the *.c and *.h files, not the Makefile.in and directory structure.... would have to test.
16:20:40 <rdieter> abadger1999: right (that's how I understand it generally)
16:20:42 <spot> racor: are you making that point in general or about the bootstrapping?
16:20:52 <limburgher> Nuke it, it's the only way to be sure.
16:21:01 <racor> spot: in general. "must be removed" is too radical
16:21:14 <abadger1999> Rathann: For compiled libs, true... configure output could lie for instance, so you'd have to check the build.log.
16:21:21 <rdieter> racor does have a point
16:21:46 <rdieter> though I've seen a fair number of configure scripts lie too (as abadger1999 mentioned)
16:22:03 <spot> yes, but i think leaving them in place just increases the likelyhood that they'll be used.
16:22:20 <spot> this is especially the case when the tooling isn't autotools
16:22:40 <abadger1999> Note that libraries also encompasses things that aren't compiled.
16:22:48 <limburgher> Exactly.  We have scads of different buildsystems being used.
16:22:58 <limburgher> Python, PHP, etc.
16:23:00 <spot> if the tooling supports opts to use external ones, then deleting the bundled copies should have no effect.
16:23:12 <racor> spot: Removing them may break things, esp. if using autotools!
16:23:15 <abadger1999> spot: Not always....
16:23:17 <spot> (and if it does, that's a bug in the tooling)
16:23:22 <Rathann> also it will let you see if upstream abuses non-public interfaces
16:23:33 * abadger1999 has seen plenty of what racor is mentioning right now.
16:23:53 <spot> abadger1999: chromium is especially bad about this, hardcoding paths for header files, for example.
16:23:59 <limburgher> Couldn't we then patch out the broken bits?
16:24:05 <limburgher> It's work, but. . .
16:24:11 <spot> limburgher: as long as the package isn't called "firefox"... ;)
16:24:18 <abadger1999> where the build scripts build the bundled libs unconditionally but only link against them if the system lib is not present.
16:24:20 <limburgher> spot <headdesk>
16:24:52 <spot> abadger1999: i think in those cases, we would either want to fix the build scripts or trick them by copying in the system so
16:24:59 <Rathann> abadger1999: well, that might produce broken binaries if system and bundled lib versions are different
16:25:29 <abadger1999> Rathann: No -- the build script builds the lib... but it doesn't then use those libraries to compile and link the program.
16:25:32 * spot would rather set a hard line policy here and deal with any fallout in exceptions
16:26:06 <rdieter> spot: +1, that maximizes sanity, minimizes badness I think
16:26:30 <abadger1999> I can vote for this, just mentioning that there's extra work involved.
16:26:41 <spot> abadger1999: sure.
16:26:42 <abadger1999> What about non-compiled libs?
16:26:57 <spot> abadger1999: like a bundled python component?
16:27:03 <racor> limburgher: patching is doable in many cases, is hard in some cases, in cases of properly implemented configurations, it's superfluous.
16:27:17 <abadger1999> Right.
16:27:28 <spot> abadger1999: i would think the same guidelines would apply.
16:27:53 <limburgher> racor  Indeed.  There may need to be exceptions, i.e. Firefox.
16:28:08 <abadger1999> So in scons, there's a few files that contain bundled code for the pyhton stdlib.
16:28:32 <abadger1999> ie: when running on python-2.4, use function foo() and bar().  When running on python-2.5 use function foo().
16:28:43 <abadger1999> The compat libs are i nthe same file.
16:28:46 <racor> limburgher:comments on firefox disclosed ;)
16:29:05 <spot> abadger1999: any reason why it isn't importing from python?
16:29:07 <abadger1999> Do we allow that because we can audit the code and see that the function won't be used?  Or do we patch it out?
16:29:28 <abadger1999> spot: It's not available in the earlier version of the stdlib.
16:29:49 <spot> abadger1999: last time i checked, try: except: worked pretty well. ;)
16:30:09 <abadger1999> In that example, bar() is first available in python-2.5's stdlib; foo() is first available in something later than python-2.5.
16:30:17 <abadger1999> spot: Right... that's how it's implemented.
16:30:32 <spot> abadger1999: then... i don't understand why the bundling is necessary
16:30:44 <spot> if it exists, use it. if not, look for the older one
16:30:47 <abadger1999> spot: But the question is -- do we need to patch the source file to remove just the function that's being bundled?
16:30:57 <abadger1999> spot: What older one?
16:31:00 <Rathann> IIUC they bundle some missing functions
16:31:06 <spot> oh, i see.
16:31:12 <spot> they're bundling deprecated functions.
16:31:15 <abadger1999> spot: The flow is t his:  If available from the stdlib, use it, if not, use the bundled version.
16:31:36 <abadger1999> spot: Opposite -- they're bundling functions that are not available on older python.
16:31:44 <spot> i would say that from Fedora's perspective
16:31:53 <spot> since we will never be shipping "older python"
16:32:23 * spot thinks
16:32:44 <rdieter> imo, the scons case is safe enough to be exception-worthy.
16:32:49 <spot> yeah
16:32:51 <abadger1999> We ship older python -- F13 has python-2.6 which is not the latest (python-2.7) and EL-5 has python-2.4....
16:32:56 <spot> i'm trying to think about how to word it.
16:33:09 <Rathann> we could patch it out, but that patch can't go upstream only after upstream decides to drop support for older python
16:33:22 <Rathann> eh... s/can't/can/
16:33:32 <abadger1999> Yeah -- I'd love to have the exception be generalizable :-)
16:33:41 <abadger1999> Rathann: Correct.
16:33:44 <spot> If the bundled code is in a code path which will never get triggered for the distribution target, then the package for that target does not need to remove that code.
16:33:59 <spot> So, for Fedora that will be true, and for older EPEL, it will be false.
16:34:12 <spot> EPEL will need to patch out the bundled code, Fedora will not.
16:34:26 <spot> how about that?
16:34:35 <abadger1999> spot: Uhm..... I think you're misunderstanding though -- if we patch out the code on EPEL, the pakcage cannot run on EPEL.
16:34:56 <spot> abadger1999: okay, so lemme back up.
16:35:14 <abadger1999> spot: Because the stdlib there does not contain that function in EPEL's version of python.
16:35:16 <Rathann> abadger1999: aren't there any backports of the missing functions? like python-kitchen?
16:35:18 <spot> the core idea behind "no bundled code" is to prevent duplication with system files
16:35:31 <racor> spot: This will not work, because RPEL already is facing problems from RHEL shipping outdated packages
16:35:33 <abadger1999> Rathann: Well... python-kitchen is in a similar position to scons here.
16:35:34 <spot> so, in EPEL, that code isn't really duplicated, hence, not bundled.
16:36:07 <rdieter> spot: right
16:36:35 <spot> So, this is a case where a package is bundling code that does not duplicate system functionality, and if it does, it is never used.
16:36:48 <Rathann> I'd say the exception is when the bundled code doesn't duplicate any code packaged for the distribution target
16:37:05 <Rathann> or is never used, yes
16:37:44 <abadger1999> Okay, that works for me as a general principle... Questions that we need to nail in the wording: "What's system functionality?  How does python's stdlib differ from a library not being included in Fedora-X"
16:38:35 <abadger1999> "If a bundled library is built but neither linked against or installed then the code path isn't being used, so why do we require it to be removed in %prep?"
16:38:41 <Rathann> well, if it's not included, but has separate upstream then normal rules apply, you have to package the separate upstream first
16:39:26 <limburgher> It's the "isn't being used".  How does Joe Packager (The Plumber's geeky brother) verify that?  Hint:  He doesn't know autotools.
16:39:36 <spot> Exception: Packages which bundle specific subsets of third-party code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled copy is not used, are exempt from the requirement to remove the bundled copy.
16:39:53 <abadger1999> "Is it legal to bundle portions of another codebase if those portions provide updated functionality to an existing Fedora package?"
16:40:06 <Rathann> if the headers of the bundled library are not used in compilation then it's OK, but can you guarantee? deleting certainly guarantees that
16:40:58 <limburgher> Rathann Exactly
16:41:05 <limburgher> Shoot the zombie in the head.
16:41:10 * abadger1999 likes spot's wording.
16:41:41 * spot uses code intentionally there, perhaps source code would drive the point home harder
16:41:43 <abadger1999> bundled s/copy/code/ ?
16:41:48 <abadger1999> at the very end?
16:41:58 <spot> abadger1999: yeah, good point.
16:42:12 <spot> Exception: Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled copy is not used, are exempt from the requirement to remove the bundled source code.
16:42:32 <spot> whoops.
16:42:36 <spot> one more sed. ;)
16:42:44 <spot> Exception: Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to remove the bundled source code.
16:43:02 * spot apologizes to racor, as that english is admittedly thick.
16:43:12 <Rathann> I'd also add that it should be mentioned in the specfile and must be verified at each update (if you're not deleting in %prep)
16:43:18 <racor> spot: legalize ;)
16:43:30 <spot> racor: guilty as charged. :)
16:44:12 <spot> Rathann: i'm fine with that
16:45:56 <abadger1999> +1
16:48:37 <abadger1999> So It's soemthing like: "Source code for bundled libraries must be deleted in %prep.  Build scripts may need to be patched to deal with this situation.  As an exception if a package bundles a specific subset of third-party source code with the '''sole purpose''' of providing functionality that is not available in the system copy and explicitly conditionalizes that use in such a way that if the system copy provides that functionality, the
16:48:38 <abadger1999> bundled source code is not used they are exempt from the requirement to remove the bundled source code.
16:49:47 <tibbs> Aargh, I got called away.
16:49:55 * spot is writing up a proper draft
16:49:56 <kalev> Should the guidelines perhaps mention that it's desireable to patch packages in such manner that the patches could be submitted back upstream?
16:50:00 <tibbs> Not usually in the office on Wednesdays.
16:50:20 <Rathann> kalev: well, dropping support for older versions is up to upstream
16:50:54 <Rathann> (talking about scons case)
16:50:58 <Rathann> but in others, sure
16:51:05 <kalev> I was just talking generally
16:51:06 <Rathann> so in general, yes
16:51:18 <kalev> one of the downsides of removing bundled libraries is that we'll have to carry patches
16:51:33 <abadger1999> kalev: It's the case for everything... but I have noticed that in this area people tend to take the easy way out rather than making patches that are upstreamable.
16:51:33 <Rathann> but we have that general guideline anyway
16:51:33 <kalev> so it makes sense to be able to submit them upstream instead
16:51:44 <abadger1999> It is much harder to do it in an upstream-friendly fashion.
16:51:53 <kalev> abadger1999: yeah, that's what I have noticed too
16:52:09 <spot> https://fedoraproject.org/wiki/PackagingDrafts/Treatment_Of_Bundled_Libraries
16:53:06 <spot> one more exception coming
16:53:33 <Rathann> sounds good to me so far
16:54:46 <tibbs> Talking about "bundled source code" in the second exception sort of makes it sound like it's supposed to be deleted from the source tarball.
16:55:12 <tibbs> Obviously that's explicitly stated earlier.
16:55:27 <tibbs> But people keep being confused by that kind of thing.
16:55:27 <spot> tibbs: yeah, i think the earlier disclaimer should cover that
16:55:28 <limburgher> Right.
16:55:49 <spot> how about i s/remove/delete there?
16:56:11 <spot> maybe even change it to say ... to delete the bundled source code during %prep.
16:56:11 <tibbs> Sure, using the same wording throughout can't hurt.
16:56:22 <Rathann> yep
16:56:33 <limburgher> Consistent and precise is good for everyone.
16:56:52 <spot> okay, change made
16:57:06 <spot> i also added the section on explicit exceptions from FESCo
16:57:37 <tibbs> Does FESCo have some sort of policy on requesting exemptions that we should link to there?
16:57:38 <spot> just to avoid the "but the guidelines say $FOO!" flame war.
16:58:00 * spot has a hard stop at 1
16:58:10 <abadger1999> spot: Link to https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
16:58:27 <kalev> is there already a page with exceptions from FESCo? Maybe a link would be useful here?
16:58:48 <spot> abadger1999: link added
16:58:53 <spot> so, in the remaining 2 minutes
16:58:55 <limburgher> There's supposed to be, with rationale.
16:59:05 <spot> we can either vote or table this until next week
16:59:09 <tibbs> I'll vote +1 on this if we're voting.
16:59:11 <abadger1999> kalev: Yep, that's the page I said to link to.
16:59:13 <abadger1999> +1
16:59:14 <limburgher> +1
16:59:15 <spot> +1
16:59:22 <Rathann> +1
16:59:30 <racor> 0 table it
17:00:13 * spot notes that we're at +5
17:00:22 <abadger1999> racor: Reason to table?  I'm in no hurry but also don't see anything still wrong with it...
17:00:27 <spot> would anyone prefer to table the item, given racor's comment?
17:00:52 <tibbs> I don't see why, but maybe I'm missing something.
17:01:03 <limburgher> racor rationale?
17:01:09 <spot> just to be non-controversial, and because i'm out of time
17:01:13 <spot> i'm tabling this until next week
17:01:20 <abadger1999> Okee dokee.
17:01:26 <Rathann> no problem
17:01:31 <spot> okay, thanks everyone.
17:01:34 <spot> #endmeeting