fpc
LOGS
17:03:12 <abadger1999> #startmeeting fpc
17:03:12 <zodbot> Meeting started Thu Jan 16 17:03:12 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:17 <abadger1999> #meetingname fpc
17:03:17 <zodbot> The meeting name has been set to 'fpc'
17:03:23 <abadger1999> #topic roll call
17:03:25 <abadger1999> Who's here?
17:03:36 * RemiFedora here (but 1h max today)
17:03:48 <abadger1999> #chair RemiFedora
17:03:48 <zodbot> Current chairs: RemiFedora abadger1999
17:03:55 * geppetto is here
17:04:59 <tibbs|w> I'm around.
17:05:07 * limburgher here
17:06:01 <abadger1999> #chair geppetto tibbs|w limburgher
17:06:01 <zodbot> Current chairs: RemiFedora abadger1999 geppetto limburgher tibbs|w
17:06:26 <abadger1999> ping racor Rathann SmootherFrOgZ FPC meeting time
17:06:32 <abadger1999> We have quorum now.
17:06:38 * Rathann here
17:06:52 <abadger1999> #topic #339     software collections in Fedora
17:06:54 <abadger1999> #chair Rathann
17:06:55 <zodbot> Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbs|w
17:07:01 <abadger1999> https://fedorahosted.org/fpc/ticket/339
17:07:17 <abadger1999> I've been working my way through creating some scls more this week.
17:07:32 * SmootherFrOgZ is half-here
17:07:35 <abadger1999> Got stuck a few times and made some updates to the metapackage spec file to address them.
17:07:37 <abadger1999> #chair SmootherFrOgZ
17:07:37 <zodbot> Current chairs: Rathann RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher tibbs|w
17:07:55 <abadger1999> Working on a small set of general scls now.
17:08:31 <abadger1999> Running into a sorta-issue where the srpm that is produced by rpmbuild -bs is not the srpm that will be produced by building the rpm...
17:09:05 <abadger1999> It's not the end of hte world because I think it's just the Name field that will differ... but I have to look into it more.
17:09:05 <RemiFedora> I think, you can use rpmbuild -bs --define "scl foo" xxx
17:09:17 <abadger1999> RemiFedora: yeah, that would address it.
17:09:25 <abadger1999> RemiFedora: But I was wondering how to address it in fedpkg.
17:09:36 <RemiFedora> (or install scl-foo-build, but it's a bad idea)
17:09:44 <abadger1999> RemiFedora: I might just note it as an issue and punt it to the fedpkg maintainers.
17:10:20 <RemiFedora> yes, else we are very probably going to be hit the "same NEVR build already exist" when truing to run a build
17:10:25 <abadger1999> RemiFedora: yeah, I was debating changing the recommendation not to install scl-foo-build to solve this but thought it was probably not the best solution :-)
17:11:01 * racor is also here, had gotten distracted on the phone
17:11:03 <abadger1999> #topic #358     Please make some autotools guidelines.
17:11:07 <abadger1999> https://fedorahosted.org/fpc/ticket/358
17:11:35 <abadger1999> No one else stepped forward here so deferring again.
17:12:03 <abadger1999> #topic #379     Proposal for guidelines changes in connection to Python 3 switch
17:12:07 <abadger1999> https://fedorahosted.org/fpc/ticket/379
17:12:13 <racor> abadger1999: I'd propose to close #358
17:12:52 <limburgher> Reasonable, they can reopen if they write a guideline.
17:13:04 <RemiFedora> agree
17:13:30 <racor> imo, a guideline on the autotools is as useful as a "how to write c"-guideline
17:13:37 <tibbs|w> I have to agree.
17:13:58 <tibbs|w> If we documented every "you could do this, or this, or this" we'd have an endless tome of "guidelines".
17:14:47 <abadger1999> OTOH, we do have a history of writing guidelines because they answer questions that come up repeatedly.
17:14:58 <abadger1999> And this is ertainly one that comes up over and over :-)
17:15:42 <limburgher> abadger1999:  True, and the guidelines are a great source of information for learning how to make RPMs, but autotools is slightly orthagonal, and besides, for 5 autotools questions there are 18 answers.
17:15:48 <abadger1999> How about I explicitly ping this week and if there's no draft we'll close next with an invitation to reopen next week.
17:15:52 <limburgher> OK
17:16:11 <geppetto> sounds good
17:16:21 <SmootherFrOgZ> k for me
17:16:23 <abadger1999> So 379.
17:16:26 <geppetto> I'd also mostly put autotools stuff in the dev. side, and not packaging so much.
17:16:58 <racor> well, if you feel like it, i don't see much sense it it and would just redirect questions to the "autobook"
17:18:45 <abadger1999> So for ticket 379...it's not written up in the form of a guideline... which was the eventual problem with the other python3 update.
17:18:56 <abadger1999> But we can discuss the general direction.
17:19:18 <abadger1999> Doing the suggestions makes the spec file a bit ugly
17:19:22 <tibbs|w> I thought the general direction was already decided.
17:19:30 <abadger1999> (main package that doesn't build a binary srpm)
17:19:50 <tibbs|w> But python packaging is already pretty terrible with ifdefs and such.
17:20:02 <abadger1999> But I can't think of anything that's really better.
17:20:20 <tibbs|w> Really it's too complicated already; making it more complicated would certainly be something to avoid if at all possible, but I'm sure everyone knows that.
17:20:44 <abadger1999> I do not agree with moving the Provides at a later date but that's something we can address at a later date.
17:21:26 <abadger1999> I'm not sure about hte other runtimes... but that can also be for the future.
17:22:00 <abadger1999> (I was hoping the ruby alt. runtimes would be good precedent but it seems that they still haven't been able to get that to work... not sure what the hold up is, though).
17:22:22 <tibbs|w> I think the holdup there is that it's basically impossible to do in a sane way.
17:23:51 <abadger1999> heh :-)  If that's true, then I'm not sure if alt. runtimes (pypy, jython) will be possible for python either.
17:24:03 <abadger1999> but like I say, that's a future worry.
17:24:04 <RemiFedora> except, perhaps, doing a mass rename of all the badly named python packages...
17:24:19 <tibbs|w> That would be a start.
17:24:39 <abadger1999> <nod>
17:25:16 <abadger1999> So perhaps one part of this is a Change Proposal to rename all the python packages so their srpm name matches python-* and their subpackages match python{2,3}-* ?
17:25:23 <tibbs|w> If it were possible to simply have some way to define a set of runtimes (2, 3, jython, whatever) a module supports and then have macros that handle the boilerplate stuff, things might get better.
17:25:53 <tibbs|w> But I doubt that's possible except in some limited cases.  And I don't know nearly enough about RPM macros to do it.
17:25:55 <abadger1999> <nod>
17:26:05 <abadger1999> tibbs|w: debian/ubuntu do things in that manner.
17:26:33 <abadger1999> They also do runtime bytecompilation... I'm not sure if that's essential to the strategy or orthogonal, though.
17:26:37 <geppetto> abadger1999: I thought they just did that for the python versions
17:26:42 <tibbs|w> Generally I object to hiding things behind macros, but exposing a nest of %if stuff as we do now is probably worse.
17:26:53 <abadger1999> geppetto: you know, that's a point I don't know the answer to.
17:27:08 <abadger1999> tibbs|w: We could get rid of the %if stuff too I suppose.
17:27:24 <abadger1999> If you build for both, just build for both.
17:28:05 <abadger1999> If you don't build for both, then use 0%{?fedora} > VER conditions
17:28:21 <abadger1999> or delete the python3 section.
17:28:25 <abadger1999> (or pyhton2 section)
17:29:54 <abadger1999> So how about I write this to the ticket:
17:30:02 <abadger1999> * Please write guidelines and we'll vote
17:30:34 <limburgher> Sounds like a plan.
17:30:42 <tibbs|w> So, basically if there has to be more complexity somewhere, great, I'd support hiding it behind macros.  But we really don't need to expose some poor packager of a simple python module to all of the intricacies of the python switchover.
17:30:51 <abadger1999> * We like the general strategy.  We have concerns about some of the future ideas but as long as those are not mentioned in the guideline update, that's fine.
17:31:56 <abadger1999> * We don't like the current complexity of the guidelines section (all the conditionals, etc).  If the new guidelines want to simplify that we wouldn't object.
17:32:45 <abadger1999> - Idea was advanced to remove the condtionals for the guidelines and just let maintainers conditionalize their specs on their own if they build on platforms that don't support both python2 and python3
17:33:49 <abadger1999> * We would like a change proposal to rename all the srpm names to match python-* and subpackages to match python{2,3}-* when we do this.
17:34:02 <abadger1999> (change proposal to fesco)
17:34:58 <abadger1999> We do mean that, right?  For instance, the python bindings shipped with libxml2 should be renamed to python2-libxml2 in that change proposal?
17:35:26 <abadger1999> (whereas currently they are libxml2-python )
17:36:57 <abadger1999> Mm... one other thing unaddressed in the wiki page --
17:37:25 <abadger1999> if a tarball claims support for both py2 and py3... do we have to build for both?
17:37:59 <abadger1999> this can cause issues when an update is needed but the update builds on py2 but not on py3, for instance.
17:38:13 <abadger1999> (because it only works on an older version of py3)
17:39:02 <tibbs|w> That would be up to the maintainer, surely.
17:39:30 <abadger1999> tibbs|w: It is now... But I'm not sure in this scheme.
17:39:43 <abadger1999> the pakcage is called "python-foo".
17:40:17 <abadger1999> if we switch the primary python installed to python3, does that mean that hte main purpose of the package is providing a python3 module?
17:40:32 <abadger1999> and the python2 module is just gravy on the side?
17:40:43 * RemiFedora searching what will be the name of "mysql-connector-python".... python#-connector-mysql...
17:41:18 <tibbs|w> I would assume that eventually we would want to get away from python2 completely.
17:41:44 <abadger1999> RemiFedora: yeah, if we recommend the Change Proposal I mentioned above, then it would be pytho{2,3}-connector-mysql (assuming that that's a python binding so python scripts can talk to mysql-connector)
17:41:46 <tibbs|w> But with all of this SCL stuff there's no "distro direction" so I guess that won't ever happen.
17:42:42 <abadger1999> tibbs|w: I think there still will be -- we'll eventually have software provided by the distro and platforms provided by the distro.
17:42:42 <geppetto> meh. I think the direction is heavily towards no py2 "long term" … the biggest problem is more than py devs. snafu'd the migration
17:42:48 <abadger1999> SCLs would be a platform.
17:43:19 <geppetto> SCLs will just help the back compat. nightmare migration.
17:43:33 <abadger1999> meld, gramps, $other_python_apps would still need a system python{2,3} to run.
17:43:37 <tibbs|w> geppetto: Yeah, python devs really missed the boat with this, but that's been discussed to death as well.
17:43:43 * geppetto nods
17:45:52 <abadger1999> RemiFedora: does the rename proposal seem okay to you knowing that?
17:46:35 <abadger1999> tibbs|w, geppetto: So.. we want to say that it's still maintainer discretion whether to build both py2 and py3 from the tarball?
17:46:52 <RemiFedora> I'm really not a python expert... but in some case (such as mysql-connector-python) it breaks the use of "upstream" name
17:48:06 <geppetto> abadger1999: I would guess so
17:48:26 <abadger1999> RemiFedora: yeah -- it breaks the parent package, child package naming.
17:48:50 <abadger1999> RemiFedora: but basically... if we want to standardize we have to specify that one or the other strategy takes precedent.
17:52:23 <abadger1999> Does anyone have a preference if we should make parent-child take precedent or $language-* for bindings?
17:52:48 * abadger1999 leans towards $language but is open to being persuaded.
17:53:17 <limburgher> I. . .sort of don't.  I like the latter, I work with someone who rather violently prefers the latter, but I can see the logic of the former as well.
17:53:54 <geppetto> I'd prefer $lang too
17:54:14 <tibbs|w> Basically, if preferring the latter makes packaging this stuff simpler, then I would do that.  Otherwise leave it the way it is currently.
17:54:34 <geppetto> I mainly prefer it because it's easier to find.
17:55:12 <tibbs|w> I'm all for anything that makes this stuff simpler for packagers.
17:55:27 <geppetto> At worst I'd much prefer it if rpm-python would provide python-rpm
17:55:57 <abadger1999> tibbs|w: Currently it's a mixture.  Some packages use libxml2-python  others use python-librepo
17:56:36 <abadger1999> limburgher: You mean, you like the former?  (libxml2-python form)?
17:57:07 <limburgher> abadger1999:  I mean I'm somewhere in between indifferent and the latter, actually.
17:57:15 <abadger1999> limburgher: okay :-)
17:58:34 <abadger1999> tibbs|w: Thinking about it as packaging... I guess the latter is slightly more complex.  You have to use For instance, in the libxml2 package you'd have to use %package -n python-libxml2  instead of %package python
17:59:04 <Rathann> abadger1999: yes, but consistency is king IMHO
17:59:29 <limburgher> But which consistency?  Following upstream or python-<foo>? :)
17:59:30 <abadger1999> It potentially makes the rules simpler if we decide this change should apply to every language binding, though.
18:00:46 <Rathann> limburgher: we already have guidelines that are exceptions from the general "Follow upstream" rule and that's a good thing
18:01:17 <abadger1999> okay, let's break this into two votes:
18:01:58 <abadger1999> Vote 1:  We want to have consistent naming for language bindings.  Either $foo-$language or $language-$foo for all packages.
18:02:06 <abadger1999> +1
18:02:21 <RemiFedora> +1
18:02:41 <geppetto> +1
18:02:52 <tibbs|w> abadger1999: Regarding complexity, I was thinking of the actual python module packaging; if specifying one naming scheme allows us to simplify rules and templates and potentially make some useful macros, then we should just do that.
18:03:04 <tibbs|w> +1 for vote 1.
18:03:48 <racor> +1
18:03:51 <Rathann> +1 to 1.
18:04:01 <abadger1999> Cool.  Vote 2:
18:04:16 <Rathann> though I'm leaning towards $language-$foo as I said
18:04:42 <limburgher> +1
18:05:12 <abadger1999> Proposal: Language bindings must be named $language-$foo, not $foo-$language (old packages grandfathered but cleanups are welcome to occur)
18:05:16 <abadger1999> +1
18:05:23 <limburgher> +1
18:05:30 <geppetto> +1
18:06:18 <Rathann> +1
18:06:34 <RemiFedora> we could have some conflicts ... I think to rrd-php vs rrd-php (both exists) and uuid....
18:06:51 <RemiFedora> well rrdtool-php and php-pecl-rrd...
18:06:52 <RemiFedora> +1
18:06:58 <tibbs|w> +1
18:07:06 <racor> +1
18:07:15 <tibbs|w> We've been big on consistency lately; might as well keep that up.
18:07:32 <limburgher> Be consistent about it, even.
18:08:27 <tibbs|w> Ugh.
18:08:34 <abadger1999> #info Proposal for language bindings to be named $lanuage-$foo, *not* $foo-$language (old packages grandfathered but cleanups are welcomed) APPROVED (+1:7, 0:0, -1:0)
18:08:39 <abadger1999> #undo
18:08:39 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x319cb790>
18:08:46 <abadger1999> #info Proposal for language bindings to be named $language-$foo, *not* $foo-$language (old packages grandfathered but cleanups are welcomed) APPROVED (+1:7, 0:0, -1:0)
18:09:09 <tibbs|w> Unanimity.
18:09:57 <abadger1999> Alright...  So on ticket 379, I'm going to update the ticket to please produce a draft with the proposed criteria.
18:10:56 <abadger1999> RemiFedora has a hard stop soon but I think we'll sitll have quorum.
18:11:00 <abadger1999> #topic #380     code::blocks bundling
18:11:04 <abadger1999> https://fedorahosted.org/fpc/ticket/380
18:11:20 <racor> abadger1999: I'll have to quit soon, also.
18:11:49 <abadger1999> k
18:11:58 <abadger1999> That will take us down to 5.
18:12:10 <tibbs|w> This is kind of missing all of the detail we generally ask for.
18:12:42 <limburgher> Yeah, ask for it, and let's move on.
18:13:15 <geppetto> seems like a plan
18:13:45 <abadger1999> <nod>
18:13:59 <abadger1999> #topic #381     Bundling exception for python-matplotlib fonts
18:14:06 <abadger1999> https://fedorahosted.org/fpc/ticket/381
18:14:15 <limburgher> This too.
18:14:27 <geppetto> yeh, similar to 380
18:14:34 <Rathann> for 380 even the author suggests astyle can be used bundled
18:14:39 <geppetto> probably felt he didn't need to because "just fonts"
18:14:45 <tibbs|w> Would like the font group to weigh in here at least.
18:14:58 <limburgher> Using system fonts can be a pain, but is The Right Thing To Do.
18:15:11 * geppetto nods
18:15:46 <tibbs|w> But if the problem is that the fonts "changed layout and names" then doesn't that imply that matplotlib would just have an old copy for eternity?
18:15:51 <Rathann> hm although it seems upstream supports building as shared library: http://astyle.sourceforge.net/install.html#_GCC_Compiler
18:15:56 <tibbs|w> Because that's not what bundling exceptions are for.
18:16:10 <limburgher> Right.
18:17:09 <abadger1999> Yeah...
18:17:27 <abadger1999> I don't see anything in the font bundling ticket that warrants an exception.
18:17:53 <abadger1999> style ticket there might be more information that would make me more positive about one way or the other being "right".
18:18:27 <tibbs|w> Would be nice if the file bug had received a better reponse, but I don't have all of the details here so I can't say who is right.
18:19:35 <tibbs|w> But it does look like python-matplotlib is simply buggy and misuses fontconfig; bundling only works around that.
18:19:53 <tibbs|w> Might be reasonable if there's a plan and timeframe for those bugs to get fixed.
18:20:19 <RemiFedora> sorry, have to go, bye
18:20:53 <abadger1999> yeah.
18:21:12 * abadger1999 will ask for that info specifically.
18:21:28 <abadger1999> #topic #383     Bundled library exception request for libgsystem
18:21:33 <abadger1999> https://fedorahosted.org/fpc/ticket/383
18:21:38 <abadger1999> This is another bundled library request.
18:21:42 <abadger1999> Also lacking in info.
18:22:05 <abadger1999> Upstream does appear to intend for it to be copied.
18:22:42 <limburgher> Oh how I love, love, LOVE copylibs.
18:22:48 <racor> abadger1999: Though they say so, they don't provide any reason.
18:22:49 <abadger1999> Do we want to say that being a copylib is sufficient or do we want to look for more information?
18:22:55 <tibbs|w> Seems to be a lot of code for a copylib.
18:23:19 <limburgher> I'd like to know for sure that it can't be packaged separately in a sane way.
18:23:22 <tibbs|w> What's a "git external" in that context?
18:23:26 <tibbs|w> (from the README)
18:23:28 <abadger1999> Note that I don't like simply accepting it on upstreams terms as we have the precedent of mono which recommended bundling libraries and we said that was not sufficient.
18:24:02 <limburgher> abadger1999: <nods>
18:24:03 <racor> abadger1999: more information - To me, this looks like an upstream, who needs to be taught.
18:24:06 <abadger1999> tibbs|w: Have git checkout the libgsystem code into your own source tree when you do a git checkout/update/etc.
18:24:26 <limburgher> abadger1999:  Eew, gross!
18:24:32 <racor> anyway, ... I need to quit now. bye
18:24:39 <limburgher> racor: <waves>
18:24:44 <tibbs|w> Yeah, that's kind of nasty.
18:25:22 <abadger1999> I've talked to the submitter and I requested more info from him.
18:25:36 <abadger1999> b/c apparently many gnome pieces are bundling this library.
18:25:48 <limburgher> <headdesk>
18:26:00 <abadger1999> (it's produced by gnome so maybe we could justify it on the same-upstream rationale)
18:26:12 <abadger1999> but also some non-gnome software (don't know how much)
18:26:27 <limburgher> Are all gnome pieces bundling the same version?  How would we know?
18:26:47 <abadger1999> which we'd either have to say isn't okay or craft a different exception rationale for.
18:26:53 <abadger1999> limburgher: Totally unknown.
18:26:54 <limburgher> If not that torpedoes the same upstream argument.
18:27:05 <limburgher> abadger1999: Oh happy day.
18:27:42 <abadger1999> limburgher: well with the gcc/gdb/libiberty/etc stuff... we said same upstream but they could be using different versions.
18:27:50 <abadger1999> The idea was if something critical came along,
18:28:05 <abadger1999> all of the things built by the same upstream would be informed and update their code.
18:28:25 <limburgher> Yeah, I know.  I still don't love it.
18:28:29 <abadger1999> But minor bugs (maybe which didn't affect your particular code) might not get an update.
18:28:39 <abadger1999> limburgher: Yeah, I agree.
18:28:40 <limburgher> Right.
18:28:47 <limburgher> Also, "yet".
18:29:01 * abadger1999 thinks of the recent libiberty flaw.
18:29:16 <abadger1999> anyhow.. also deferring for more info needed.
18:29:26 <abadger1999> #topic #382     Go Packaging Guidelines Draft
18:29:29 <abadger1999> https://fedorahosted.org/fpc/ticket/382
18:29:32 <tibbs|w> So why would anyone depend on this libgsystem stuff?  It has no stable upstream versioning and no bug tracker.
18:29:57 <tibbs|w> And we get into another language which actively resists distro packaging.
18:30:47 <limburgher> tibbs|w:  Honestly no idea, it must, like, wash your car and bathe your dog or something.
18:31:34 <abadger1999> This part is confiusing: Most of the golang-* packages are source code only, the *-devel sub-package that includes the source code, should explicitly have provides for the golang imports that it includes.
18:32:00 <abadger1999> That sounds like the language does not suppport libraries (even static libraries) at all.
18:32:13 <limburgher> So. . .
18:32:19 <tibbs|w> Basically, go doesn't appear that it has precompiled libraries; it just concatenates the source for every dependency and crams it all together.
18:32:27 <tibbs|w> I believe this is seen as a feature.
18:32:33 <limburgher> What could possibly go wrong?
18:32:54 <tibbs|w> At least with caml the language explicitly fails when any of the dependencies changes.
18:33:32 <tibbs|w> So you're forced to rebuild the entire world constantly, but at least you get lots of nice rpm dependency stuff to tell you that.
18:33:39 <abadger1999> yeah
18:34:06 <limburgher> I. . .
18:34:24 <abadger1999> Hmmm
18:34:26 <abadger1999> The standard golang compiler only produces static libraries. There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler. Instead, each library package should consist of a -devel subpackage which installs .go source code to /usr/share/gocode/src, under the appropriate import path.
18:34:29 <abadger1999> hah.
18:34:34 <abadger1999> So *sigh*
18:34:49 <tibbs|w> So I guess what's needed is the "rebuild the world" behavior, but enforced through packaging guidelines and rpm dependency information.
18:35:12 <limburgher> tibbs|w:  Or something else I'm far too polite to mention.
18:35:13 <geppetto> riiiight
18:35:32 <tibbs|w> Or should changes in dependencies just be allowed to be ignored until rebuilds just happen to get done?
18:35:42 <geppetto> I'm think soem form of "here's 2 cents, go make yourself some real infrastructure"
18:35:45 * abadger1999 wonders if that even works.
18:36:19 <abadger1999> I guess if the check as to whether the library was created with a buildtime check rather than a runtime check that would.
18:37:08 <geppetto> I guess this _could_ be thought of as the end form of C++'s header only libs.
18:37:09 <limburgher> By brain is chasing this, but my cold medicine is around my brain's ankles, and I'm not sure I can catch it.
18:37:12 <abadger1999> So thinking about this... do we want packages to rebuild whenever their dependencies are rebuilt?
18:37:20 <abadger1999> rebuilt/updated?
18:37:29 <limburgher> Only if the solib name cha. . .oh, yeah, that.
18:37:31 <geppetto> And if it worked like that, I guess it's not completely insane.
18:37:58 <limburgher> geppetto:  Uh, I guess.  Maybe.
18:38:13 <abadger1999> With shared libraries, we do want the dependent packages to start using the new shared library's code -- which they do automatically.
18:39:06 <limburgher> So by extension, does that mean that the reverse is true for Go?
18:39:16 <abadger1999> if we want the same behaviour here, then we might as well precompile knowing that all go packages must be recompiled when something further down the dep chain updates
18:39:27 <tibbs|w> Propose we just ask back how they want dependency version tracking to be done.
18:40:18 <tibbs|w> They just say "rebuild if there's a security concern" and I personally don't think that's quite good enough for an entire language stack.
18:40:24 <limburgher> No.
18:45:49 <abadger1999> So.. our static library guidelines don't seem t orequire dependent packges to rebuild everytime:
18:45:51 <abadger1999> If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are instructions for making that request.
18:46:11 <abadger1999> ie: watch for issues but not required to take action.
18:46:51 <abadger1999> So the source packages might mirror that more closely than requireing packages to rebuild.
18:47:02 <abadger1999> OTOH, the static guidelines won't scale to this usage.
18:47:29 <abadger1999> as it's not just I required a static library.
18:47:50 <abadger1999> It's also I required a static library that requires another static library that requires another static library [...] n levels deep.
18:47:57 * geppetto nods
18:49:04 <geppetto> I guess people can just have less deps.
18:49:17 <abadger1999> ha :-)
18:49:34 <abadger1999> Like not deping on Go? ;-)
18:49:39 <limburgher> But packages who need packages are the happiest packages of all!
18:49:45 <geppetto> Well … being required to put yourself on the CC for 20 other packages would be a big incentive to not add deps :)
18:50:13 <abadger1999> I know, I'll bundle instead!
18:50:34 * limburgher smacks abadger1999 with a large fish
18:50:49 <tibbs|w> If it were possible to do something like ocaml does with the library checksums, that might be nice.
18:50:59 <abadger1999> limburgher: http://www.darthsanddroids.net/episodes/0208.html
18:50:59 <geppetto> But, yeh, I'm not completely against saying "having a huge number of static. libs. is likely unmanageable in a distro. … feel free to come back when you've fixed that"
18:51:10 <abadger1999> limburgher: consider me splatted.
18:51:44 <limburgher> abadger1999:  Sweet!
18:51:58 <limburgher> geppetto:  <nods>
18:52:25 <geppetto> tibbs: How does that work … I thought that was just a way to make sure everything was the same versions as when built
18:53:00 <geppetto> tibbs: So if you dep. on X which deps. on Y, and Y then gets changed+rebuilt … when you rebuild X fails because Y changed since it built.
18:58:38 <abadger1999> oaky -- anyone want to take point on summarizing issues for this ticket?
18:59:00 <abadger1999> Or we could all add problems that we saw to it.
19:02:43 <abadger1999> #info FPC members, please add problems you see with the golang guidelines to the ticket.  We'll see if there's a way  to address them afterwards
19:02:55 <abadger1999> We're over our two hour mark and people have pretty much gone silent.
19:03:03 <abadger1999> So I'll close out the meeting in 30s
19:03:20 <tibbs|w> geppetto: Sorry, had to answer the door.
19:03:35 <tibbs|w> Just look at the deps of an ocaml lib and it should be pretty obvious.
19:03:54 <tibbs|w> Now, I don't know what generates those hashes, but I think it's just rpm macro magic.
19:05:16 * geppetto nods
19:09:29 <abadger1999> #endmeeting