16:03:27 <abadger1999> #startmeeting fpc
16:03:27 <zodbot> Meeting started Thu Oct  3 16:03:27 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:37 <geppetto> RemiFedora: No SCL this meeting … so should be manageable ;)
16:03:42 <abadger1999> #chair limburgher geppetto tibbs|w SmootherFrOgZ RemiFedora
16:03:42 <zodbot> Current chairs: RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher tibbs|w
16:03:43 <RemiFedora> :)
16:03:52 <geppetto> Although we do have a backlog now
16:03:58 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/344 Wrong library name conflicts solution
16:04:11 <abadger1999> mschwendt's analysis looks spot on.
16:04:23 <abadger1999> the question is what to change the recommendation to.
16:05:00 <RemiFedora> I agree, different dir is a bad idea
16:05:06 <limburgher> Assuming we want to avoid an explicit Conflicts.
16:05:21 <geppetto> yeh, I guess because the only real fix is that some upstream needs to rename their lib.
16:05:39 <limburgher> geppetto:  In a perfect world.  That's one brane over.
16:05:40 <RemiFedora> and 1 more point, both will have the same "provides" so dep resolve will be broken
16:06:30 <RemiFedora> (not 1 more point, already writen at the end of the ticket)
16:08:20 <abadger1999> How about rpath, would that work?
16:08:46 <geppetto> It would … as long as both libraries aren't needed
16:09:06 <geppetto> And one of the libraries needs to be put in the magic rpath dir.
16:09:34 <limburgher> At which point Conflicts is simpler.
16:09:43 <geppetto> yeh
16:10:09 <limburgher> Absent upstream cooperation, I think we're after Least Yucky.
16:10:25 <abadger1999> Proposal:
16:10:31 <abadger1999> If the library is 100% ABI-compatible, you can use environment-modules[LINK] let the user switch between them.  If the library is not 100% ABI-compatible an option is to put the libraries into different subdirectories of %{_libdir} and compile the specific programs which link with them to use an RPATH to the library.  The preferred option is, of course, to convince one of the upstreams to rename their library.
16:10:32 <abadger1999> {{admon/note||Do not create an /etc/ld.so.conf.d/ file for the library.  This just reintroduces the conflict at runtime when the user runs the program.}}
16:10:53 <geppetto> I mean there are cases where conflicts is too strong … but, I'd be tempted to go even further and say the "new" libeio can't exist.
16:11:10 <limburgher> geppetto:  Elaborate that last.
16:11:36 <geppetto> limburgher: If upstream is being stupid and picking library names that are already taken … force them to fix it.
16:12:16 <limburgher> geppetto:  Not a bad idea.  I mean, I even Google names stuff I write that I never intent to release.
16:12:17 <RemiFedora> missing a note about the autodep.
16:12:38 <Rathann2> or carry a renaming patch in Fedora until they fix it
16:12:51 <limburgher> Or Conflict until the fix it.
16:12:51 <abadger1999> RemiFedora: that would go in the admon/note?
16:12:52 <limburgher> they
16:13:18 <RemiFedora> "The library (outside of the default linker path) should be filtered from auto-provides (and explicitly required when needed)
16:14:10 <limburgher> This just seems like a case of, "when two upstreams aren't playing nice, ignore our usual practices in the following ways. . . "
16:14:14 <abadger1999> ah... /me conveniently forgot that autodeps would find libraries outside of the linker path.
16:14:36 <tibbs|w> Does it now?  RPM behavior has changed there recently.
16:14:42 <geppetto> So looking at 1003692 … that seems to be how they fixed it (one of the libeio's got removed from Fedora).
16:14:43 <abadger1999> limburgher: well the problem is that sometimes the two upstreams are both stuborn.
16:15:08 <abadger1999> and we do want both libraries in fedora (for some definition of "we")
16:15:09 <limburgher> abadger1999:  Which Conflicts would work around.
16:15:27 <geppetto> So I think we should just add documentation saying "if they are different opt. compiles/etc. … use the dir+ld.so.conf trick, if not one of them has to die or rename"
16:15:55 <abadger1999> limburgher: Hmm... that is a good point -- I've been thinking we might want to revisit the basic assumption that Conflicts cannot be allowed in Fedora.
16:16:32 <tibbs|w> Conflicts on libraries are pretty scary, though.
16:16:51 * abadger1999 would rather relax the Conflicts rules than say one has to die.
16:16:57 <tibbs|w> You can end up with trees of packages that can't be installed together because of dependencies.
16:16:58 <limburgher> tibbs|w:  Indeed.  They rely on the users to know what they really need and are doing, which is a large assumption.
16:17:08 <abadger1999> tibbs|w: yeah -- because then a machine can only be used for one purpose or the other, not both.
16:17:53 <geppetto> I'm not 100% against allowing conflicts, but I think it's much easier for everyone if you just say "no, stop being stupid and rename"
16:18:01 <limburgher> Ok, let's look at it from this angle.  Is it likely that a person/developer/application would ever need/want both of these libs?
16:18:36 <limburgher> I mean if I wrote an app that needed both, would it do anything useful?  Would it compile?
16:19:04 <abadger1999> limburgher: more than that... I might want to install enlightenment window manager and mc file manager but if they both have something different called libeio they wouldn't both be installable.
16:19:12 <geppetto> limburgher: With conflicts the problem is things like developer work station uses blah desktop needing one lib. and blah web server setup that needs another.
16:19:16 <abadger1999> so it's not necessarily about the user knowingor not knowing.
16:19:19 <limburgher> abadger1999:  Right.
16:19:54 <limburgher> So Conflicts is probably the wrong way to go.  But I think abadger1999's proposal is too risky.
16:20:16 <limburgher> I'd rather have the younger upstream place nicely.
16:20:58 <limburgher> I mean there's libjpeg and libjpeg-turbo, it can happen.
16:21:37 <abadger1999> limburgher: that's not a good heuristic either... This section is filled with value judgements because the case is often not clear cut: https://fedoraproject.org/wiki/Packaging:Conflicts#Approaching_Upstream
16:22:10 <limburgher> abadger1999:  Yeah.  I know.  Just being idealistic.  Again. :)
16:22:11 <abadger1999> hi, I've been around since 1994! vs hi, 80% of the people looking for libfoo are actually looking for me!
16:22:46 <geppetto> abadger1999: yeh, there's that.
16:23:09 <geppetto> But hopefully there are very few cases that will be that bad.
16:23:43 <geppetto> and most of the time we can just go "there is a conflict, what you are conflicting with is already in Fedora … sucks to be you, change the lib. name"
16:23:50 <limburgher> I would not alter my respiration rate on that basis.
16:24:04 <limburgher> geppetto: <nods>
16:24:05 <abadger1999> *cough*mock*cough*pip*cough*
16:24:32 <geppetto> pip?
16:24:39 <abadger1999> python-pip vs perl-pip
16:25:18 <geppetto> ahh, I'd ban them both as not being rpm ;)
16:25:27 * geppetto ducks
16:25:48 <abadger1999> thanks to a cooperative fedora maintainer, we finally have python-pip using the pip name.  but the perl-pip is definitely older and the naming problem was pointed out to the python-pip author when the software was young and had a chance to be a good netizen.
16:26:07 <abadger1999> *cooperative fedora perl maintainer
16:26:20 <geppetto> but, seriously … I doubt it happens enough to think about much … just put something in saying if you really think you shouldn't have to rename and can't work it out then open an FPC ticket.
16:26:29 <abadger1999> I'm not bitter about upstreams, though.
16:26:45 <geppetto> haha
16:28:21 <limburgher> So no nightmares about the appearance of ruby-pip then?
16:30:22 <abadger1999> Proposal: If the library is 100% ABI-compatible, you can use environment-modules[LINK] to let the user switch between them.  If the library is not 100% ABI-compatible get one of the upstreams to rename.  See [LINK] for ideas on persuasion.  If neither upstream will budge, <strike>open a ticket for FPC to ban both libraries from Fedora</strike>
16:30:34 * abadger1999 needs to find something to replace <strike> :-)
16:30:53 <limburgher> <drone strike> ?
16:31:37 <Rathann2> I hope the ban both part is a joke
16:31:45 <geppetto> I laughed :)
16:31:58 <abadger1999> Rathann2: yep.  Filler text.  I need something to put there.
16:31:58 <geppetto> +1
16:32:04 <abadger1999> #chair Rathann2
16:32:04 <zodbot> Current chairs: Rathann2 RemiFedora SmootherFrOgZ abadger1999 geppetto limburgher tibbs|w
16:32:06 <Rathann2> ah
16:32:10 <Rathann2> that's what you meant
16:32:46 <abadger1999> If neither will budge open a ticket for FPC to evaluate what sort of hoops both packages would need to implement to not conflict at runtime.
16:33:11 <abadger1999> Maybe that.  and then the first time we have to deal with it, we write those into the recomendation.
16:33:13 <Rathann2> well the only reasonable solution is to rename, so the next step would be to open cross-distro discussion about carrying a patch to rename
16:33:26 <limburgher> abadger1999: Yes, that.
16:33:39 <RemiFedora> "well the only reasonable solution is to rename" +1
16:33:40 <Rathann2> works for me as well
16:33:52 <abadger1999> +1
16:33:59 <limburgher> Call one "libweasel" or something. :)
16:34:01 <limburgher> +1
16:34:03 <tibbs|w> +1
16:34:10 <SmootherFrOgZ> +1 on new proposal
16:34:28 <Rathann2> +1 to latest abadger1999's proposal
16:34:31 <geppetto> +1
16:36:16 <abadger1999> #info New recommendation for library conflicts approved (+1:6, 0:0, -1:0)
16:38:04 <abadger1999> #topic Ruby guidelines: Filtering automatic provides  https://fedorahosted.org/fpc/ticket/345
16:38:42 <limburgher> Closed Invalid.
16:38:55 <abadger1999> This was closed because rpm in f20+ does this on its own.
16:39:12 <abadger1999> We probably should make a note of that in all the other guidelines that are filtering.
16:39:48 <abadger1999> (and I  suppose that might also have an impact on the previous ticket depending on what the heuristic to determine "library" is)
16:39:48 <limburgher> Yeah.
16:39:58 <abadger1999> Anyone want to volunteer to do that?
16:40:15 <tibbs|w> Is there documentation for exactly what RPM does now?
16:42:29 <abadger1999> I'm guessing it's this change: "New ELF dependency generator option --no-fake-soname to prevent emitting soname provide when DSO does not set one"  http://www.rpm.org/wiki/Releases/4.11.0
16:42:49 <abadger1999> But that's just a one line entry, not in depth information.
16:42:57 <tibbs|w> That seems interestingly limited.
16:43:04 <tibbs|w> I figured it was based on directories somehow.
16:43:28 <abadger1999> that line would imply it does not help with the previous topic.
16:43:57 * geppetto copy and pastes
16:43:58 <geppetto> - Instead of vain heuristics on DT_SONAME presence, filter out
16:43:58 <geppetto> irregular sonames from all dependencies: linkable library names generally
16:43:58 <geppetto> must contain ".so" and start with "lib" for the linker to find it at all,
16:43:58 <geppetto> anything else is an exception of one kind or another (the prime exception
16:43:58 <geppetto> of ld.so variants we handle here). This weeds out provides for most
16:43:59 <geppetto> dlopen()'ed modules etc, and filtering both provides and requires
16:44:01 <geppetto> by the same rules means we wont generate requires for things that wont be
16:44:07 <geppetto> provided.
16:44:51 <RemiFedora> "lib" prefix seems to be enough for most cases
16:45:04 <abadger1999> well, i'll open up a task to review and note the f20 timeframe for the other filter macros.
16:45:13 <RemiFedora> like the one in the ruby ticket (and also the case for all the php modules)
16:46:34 <RemiFedora> (except libvirt-php.so awfull one)
16:46:52 <Rathann2> so after the next mass rebuild cycle we should end up with a lot less dependency metadata, nice
16:48:18 <RemiFedora> but the ticket was to add %{?ruby_default_filter} as %{?perl_default_filter}
16:48:54 <RemiFedora> I think this could stay (even if rpm have a nice auto-filter, and the macro definition will be simplified)
16:49:10 <abadger1999> added: https://fedorahosted.org/fpc/ticket/353
16:49:31 <abadger1999> RemiFedora: If you have a suggestion for what the macros should look like, add it to ticket/353 .
16:50:27 <RemiFedora> %ruby_default_filter %nil   ;)
16:51:01 <abadger1999> ah.. for the I want to build on rpm less than f20 case?  Yeah, could be done.
16:51:15 <RemiFedora> exactly
16:51:39 <limburgher> Which will come up constantly, people git merging from f20 to update f19, etc.
16:51:49 <abadger1999> We'd still need to identify all the cases and update the macros in those packages.
16:52:12 <abadger1999> RemiFedora: Do you want to figure out what those are and we can discuss it at the next meeting?
16:52:58 <abadger1999> #topic Bundling exception request for Eclipse Sisu https://fedorahosted.org/fpc/ticket/346
16:53:02 <RemiFedora> yes I will search for the existing filter macro
16:55:19 <abadger1999> #action RemiFedora to research what filter macros would need to be updated and add to https://fedorahosted.org/fpc/ticket/353
16:56:36 <abadger1999> I'm thinking that since there's a plan to do this like a static library I could be okay with this ticket.
16:56:37 <geppetto> this seems like a giant "sigh, why are upstreams so stupid"
16:56:53 <abadger1999> but yeah, otherwise I agree with geppetto.
16:56:59 <limburgher> Yeah. :(  Me too.
16:57:55 <geppetto> It seems like the "right" thing to do is rename the new lib. asm4 … but I'm guessing that's going to be a giant mess of educating java developers.
16:59:09 <geppetto> Does anyone know if this is intended to be temporary … and eventually all/enough things will migrate from asm3 that we can unbundle everything and just have asm-4 ?
16:59:52 <Rathann2> hm what's the asm's package name
16:59:52 <abadger1999> we can ask.
17:01:23 <Rathann2> oh...
17:01:32 <Rathann2> actually we have three versions of asm
17:01:54 <RemiFedora> asm2, objectweb-asm (3) and objectweb-asm4
17:02:03 <Rathann2> asm2, objectweb-asm (=3.x) and objectweb-asm4
17:03:16 <Rathann2> hm so the solution would be to migrate everything to asm4
17:03:46 <abadger1999> note, asm2 is retired in rawhide (blocked in f20)
17:05:23 <RemiFedora> I think, when asm3 will be retired... we'll probably have asm5 and asm6
17:06:44 <abadger1999> Rathann2: well.... so that's part of the correct solution.  But there's two difficulties: 1) do we require fedora maintainers to do that (case could be made that yes we do) 2) do we not want to do that in this case because there's third party extensions that run on top of this application that would depend on an exact version of asm (case could be made that we don't worry about things that are not in fedora or things that are not-opensource..
17:06:46 <abadger1999> . but I'm not sure if that's a current model or only from the early days of fedora.)
17:07:25 <abadger1999> I guess #2 is something we'd need to ask fesco.
17:08:18 <Rathann2> I'm not sure I understand the original sisu issue that lead to bundling
17:08:54 <abadger1999> Rathann2: sisu is extendable by plugins.  Those plugins could be using the asm library.
17:08:58 <Rathann2> and from the fpc ticket: Currently version 3 is directly used by 64 packages, so migration to version 4 is practically impossible, at least not any time soon. Version 4 is used by 13 packages.
17:09:25 <Rathann2> are we expecting more asm4 bundling exceptions?
17:09:33 <abadger1999> Rathann2: I think the motivation from sisu upstream is to be able to namespace the symbols their copy of asm uses so that the plugins can use a different version than they do.
17:09:37 <geppetto> around 13 more?
17:10:07 <RemiFedora> Rathann2, I think this bundling exception is because maven is part of the build system
17:10:32 <abadger1999> ie: sisu upstream has moved on to asm4 like a good open source project.  But not all plugins  for sisu are as proactive.
17:10:57 <RemiFedora> so to be able to build module with asm 3 or 4 without having conflicts with version used by the build system
17:10:58 <abadger1999> so those can't run inside of sisu if they are built for the older version of asm.
17:11:39 <Rathann2> ok so either we reject and tell them to fix all the plugins that are in Fedora first or we grant a temporary exception until the plugins have moved to asm4
17:11:45 <abadger1999> RemiFedora: uhm.... wouldn't that only be the case if the build system had to use the library?  Just compiling and linking shouldn't cause that?
17:12:01 <RemiFedora> .. java ...
17:12:17 <abadger1999> or a permanent one since their proposal is akin to static linking rather than true bundling.
17:14:53 <abadger1999> So -- I guess we need to ask: FPC is much more inclined to grant a temporary exception than a permanent one as this is a case where the plugins need to catch up with the core.  Can you give us a time frame that we could grant a temporary exception for?
17:15:19 <abadger1999> And if they say, "no". or "15 years" then we can revisit whether this is enough like static linking that we're okay with it?
17:15:24 <Rathann2> I wonder why they can't just make the new sisu version require that all plugins also use asm4
17:15:34 <abadger1999> Rathann2: because upstreams are dumb :-)
17:15:47 <abadger1999> They want to accomodate their users.
17:15:52 <abadger1999> but at the expense of maintainance.
17:16:00 <Rathann2> *sigh*
17:16:35 <abadger1999> and the maintainance burden isn't obvious upfront -- only after there's some problem that they/we are forced to fix without help from the library upstream.
17:16:42 <RemiFedora> IIUC, this are extensions of Maven, not extension of Sisu
17:17:49 <Rathann2> ah so we're actually waiting for maven and its plugins to move to asm4
17:18:19 <abadger1999> RemiFedora: <nod> yeah, I agree.
17:19:17 <RemiFedora> So I think I agree with bundling (or static) lib exception for this case.
17:19:32 <RemiFedora> but we can ask more info if you prefer
17:19:52 <abadger1999> k
17:20:07 <Rathann2> hm on F18 yum install maven actually tries to install both asm3 and asm4
17:20:15 <geppetto> :)
17:20:20 <abadger1999> Nice :-)
17:20:36 <Rathann2> so I wonder how much of an issue it is
17:21:28 <RemiFedora> on F19, maven only use asm3 (I can remove asm4 without removing maven)
17:21:44 <geppetto> on F20 seems to just try asm
17:22:00 <limburgher> Keep in mind use != Require, if someone messed up.
17:22:24 <RemiFedora> yes
17:22:38 <abadger1999> #action abadger1999 to request more information on https://fedorahosted.org/fpc/ticket/346
17:22:47 <Rathann2> on F18 the dependency is maven -> animal-sniffer -> objectweb-asm4
17:22:53 <abadger1999> Okay -- do we want to try to hit another one or two topics or wrap up for the day?
17:23:12 <limburgher> As much as I'd love to keep on I'm getting E_BLOOD_SUGAR
17:23:31 * abadger1999 hasn't had breakfast yet -- knows the feeling.
17:23:43 <abadger1999> So let's wrap up
17:23:44 <limburgher> WHich stinks cuz I'd like to hit the jthread one.
17:23:49 <limburgher> k
17:24:00 <abadger1999> is it (jthread) easy?
17:24:21 <limburgher> Not really.  MAybe.  Could we discuss and maybe vote in ticket?
17:24:34 * RemiFedora have to go
17:25:26 <limburgher> discuss in ticket as well, I menat.
17:25:28 <limburgher> meant.
17:27:40 <abadger1999> wfm
17:27:56 <abadger1999> okay, going to close in 1 minute unless anyone has something.
17:28:05 * SmootherFrOgZ has nothing
17:29:30 <abadger1999> #endmeeting