[00:08] <Unit193> infinity: Looking forward to the American election too, eh?
[01:26] <teward> for my own reference, if I update a package in the repositories that another relies on, and the package that relies on mine depends on it, how would a rebuild be issued, or what would be the most sensible way to approach that?  Hypothetically.
[01:27] <infinity> teward: Why would a rebuild be necessary?
[01:27] <infinity> teward: Are you talking an SONAME bump in a library, or similar?
[01:29] <infinity> teward: Anyhow, if there's a library transition in play, you do something like "pull-lp-source foo && cd foo-* && dch -R", enter a changelog entry like "Rebuild for the libbar transition.", and upload.
[01:30] <infinity> teward: But first, I'm curious about specifics, rather than hypotheticals.  We don't rebuild rdeps unless there's a reason.
[01:30] <teward> infinity: with regards to https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-June/016654.html, https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007360.html, and https://lists.ubuntu.com/archives/ubuntu-server/2016-June/007361.html
[01:31] <teward> infinity: basically, it's on the discusison list - if there is a package with a .so dynamic module built against 1.10.1 and we release 1.10.2 for bugfix/security reasons, a package with the .so dynamic module would need a rebuild
[01:32] <teward> reading up on the thread may make the reasoning more clear?
[01:32] <teward> more or less to try and understand weird edge cases
[01:33] <teward> granted, i've not yet merged in Debian's dynamic module handling yet, which might be a pre-req
[01:33] <teward> rbasak: fyi ^
[01:33] <infinity> teward: Having the server ABI tied to version is madness.
[01:34] <teward> I told nginx upstream their dynamic modules approach doesn't work well in downstreams
[01:35] <infinity> teward: But, if we're stuck with that for now, then any rdeps in the archive would need a rebuild on upgrade, yes.  And they better have proper dependencies based on some nginx-signature-12345 provides or something.
[01:35] <teward> got a reply "Yeah we know, we'll work on it but it's not a short-term goal"
[01:35] <infinity> teward: It's not hard to fix.  All they need is an ABI tracker that bumps signature if and only if the ABI breaks.  Which means some rebuilds, but not on every version.
[01:35] <infinity> (This is basically the PHP approach)
[01:36] <infinity> teward: Anyhow, does nginx actually have rdeps in the archive right now?
[01:36] <teward> infinity: for now, no.  come next LTS, probably.
[01:36] <teward> or sooner, if people start putting things into Debian for third-party modules
[01:36] <infinity> So, let's solve this properly before then.  For both Debian and Ubuntu.
[01:37] <infinity> Modules need to have a specific exported ABI to depend on, so they don't have to depend on nginx (>> foo), nginx (<< bar) | nginx-foo (<< foo) ...
[01:37] <infinity> You can see how that gets ugly quickly.
[01:37] <teward> indeed
[01:37] <teward> I think this is something that should be deferred until nginx can fix things?
[01:37] <teward> because the way they've got things done, at least AIUI, there's no ABI-based handling
[01:38] <infinity> You can fake one.
[01:38] <teward> infinity: guidance on that would be appreciated
[01:38] <infinity> Remind me when it's not... Today.
[01:38] <teward> works for me :)
[01:39]  * teward looks back at the nagios page saying all his Ubuntu Server VMs are down, and figures he should probably fix them instead of worrying about nginx :P
[01:39] <teward> (at least for right now)
[01:40] <infinity> teward: As for upstream, they need to track ABI, but what they do with that information is another question.  They *could* export an ABI define somewhere, that people could test against.  Or, they could go the sane route, and promise ABI stability in a major.minor (or even just major) series.
[01:41] <infinity> teward: The latter would be much better, but it means checking for ABI breaks in upstream commits and blocking them or backing them out of people oops.
[01:41] <infinity> s/of people/if people/
[01:41] <teward> infinity: I think ABI breakage is more prone in mainline (1.9.x as an example) than 1.10.x which basically doesn't change once released
[01:41] <infinity> Well, "basically doesn't change" isn't a promise. ;)
[01:41] <teward> except for bug fixes, and I think that nginx is smart enough to make notices about it
[01:42] <teward> well, with dynamic modules being a 'new' thing with 1.9.x, 1.10.x, I think they'd put "This may break third party dynamic modules" over the lists i'm on
[01:43] <teward> and that'd prompt the need to poke rebuilds or 'fake' an ABI change
[01:43] <infinity> Not if the ABI signature checked at load time is based on the version, they won't. :P
[01:43]  * teward yawns
[01:43] <infinity> Cause, in their mind, they break modules regardless.
[01:43] <teward> infinity: I get what you're saying, i'm basically dead here.
[01:43] <infinity> Anyhow.  Another time.
[01:43] <teward> um, clarify "they"
[01:43] <teward> there's nginx upstream, Google PageSpeed upstream, and us :p
[01:44] <infinity> They, upstream.  They're not going to inform you if a change may break modules, because their "ABI" breaks on every version change anyway.
[01:44] <teward> (there's two upstreams)
[01:44] <infinity> nginx upstream. :P
[01:44] <teward> :P
[01:44] <teward> well
[01:44] <teward> i have an evil painful workflow that I currently do for a few home-grown packages which depend on others
[01:45] <teward> basically a shell script that builds one, pulls in for the build env on a separate package, and tests.
[01:45] <teward> but eh
[01:45] <infinity> We can talk more later.  I have a hot date with a shawarma.
[01:45] <teward> could potentially adapt, but CBA to bother now
[01:45] <teward> heheheh, enjoy infinity
[01:45] <teward> i'm going to go find coffee...
[01:45] <teward> and fix my servers... (I think the hypervisor powercycled...)