18:59:36 <marga> #startmeeting
18:59:36 <MeetBot> Meeting started Wed Oct 16 18:59:36 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:47 <marga> Ah, maybe I should ping. Sorry
18:59:53 <marga> MeetBot, pingall Meeting starting!
18:59:53 <MeetBot> Meeting starting!
18:59:53 <MeetBot> abrotman adsb berni bremner buxy carnil doko dondelelcaro dwfreed fil gregoa gwolf h01ger jcristau marga MeetBot Mithrandir ntyni OdyX ScottK smcv spwhitton themill weasel zigo
18:59:53 <MeetBot> Meeting starting!
19:00:04 <marga> #topic Roll Call
19:00:12 <bremner> David Bremner
19:00:12 <marga> Welcome to our October meeting, who's around?
19:00:17 <marga> Margarita Manterola
19:00:32 <fil> Philip Hands
19:01:26 <OdyX> Didier Raboud
19:01:40 <ntyni> Niko Tyni
19:02:11 <marga> gwolf said that he wouldn't be able to attend. Did anybody else give notice?
19:02:53 <marga> I guess not.
19:02:55 <marga> #topic Review of previous meetings AIs
19:03:17 <marga> Gunnar had an AI of closing 932795, which he did. Woohoo!
19:04:06 <marga> Mithrandir had an AI of discussing with the Community Team whether the communication issues identified in #934948 would be something that they would be willing to take on.
19:04:35 <marga> Given that he's not around, does anybody else happen to know if that went anywhere?
19:05:58 <OdyX> Nope
19:06:13 <bremner> the CT (not to be confused with the TC) seems to be busy with establishing it's place / delegation / rules-of-engagement
19:06:34 <Mithrandir> I talked to them, they were going to involve themselves and see what they could do.
19:06:51 <bremner> cool
19:06:56 <marga> Ah, awesome!
19:07:00 <Mithrandir> Not really here, on phone irc
19:07:02 <marga> Thanks!
19:07:13 <fil> great, thanks
19:07:44 <marga> Alright, one last AI (mine). I was supposed to create a summary of our many discussions around the role of the TC and I failed to do this, my work life keeps eating all my time/energy. :-/
19:08:20 <marga> We don't have a lot of topics for today. So, let's do them one by one.
19:08:31 <marga> #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment
19:09:01 <marga> Given that the CT is going to see if they involve themselves, is there anything for us to do?
19:09:43 <bremner> was it _only_ miscommunication, or was there some technical question (that didn't involve overriding delegates)?
19:10:09 <bremner> I mean, I guess we had some discussions about best practices?
19:10:31 <marga> Yeah, but in the end there's a lot of gray areas that depend a lot on the case?
19:11:45 <marga> It's not clear from reading the information that we have the exact technical reason why the package was rejected.
19:12:28 <bremner> or if such a reason exists.
19:12:29 <marga> It's likely that it was the right decision, but we would need to investigate further to make that assessment and we know already that we can't overrule, so...
19:13:34 <fil> do we get to change the decision, even if we somehow came to the conclusion it was wrong? (I thought not)
19:13:42 <bremner> no
19:14:00 <fil> thought not ... next
19:14:03 <bremner> but there is a general question of best practices with respect to bundling.
19:14:17 <fil> yeah, fair enough
19:14:18 <marga> Right, we can't change the decision, but we can offer advice in general
19:14:37 <marga> (which is what was asked from us)
19:15:00 <bremner> and I think marga opened with being skeptical that we could give useful advice; I don't necessarily disagree.
19:15:13 <bremner> (in this instance :P)
19:15:33 <OdyX> The delegates communicated in a way that could be improved. But they didn't really indicated they'd welcome our input there?
19:15:40 <marga> Yeah, I'm not sure we can give general advice about this, because too much depends on the exact details.
19:15:56 <marga> The delegates didn't ask for our advice, no.
19:16:28 <fil> quite -- useful advice seems likely to be used as a stick to beat someone, somehow ... unless it's so bland as to be not worth producing
19:16:53 <bremner> fil: you're not wrong, but we nonetheless have Debian Policy
19:16:55 <marga> Agreed
19:17:07 <bremner> which is indeed used as a stick, but still has some benefits.
19:17:08 <marga> (with fil, sorry)
19:17:57 <OdyX> I think FTP-master are aware they could be clearer.
19:18:14 <OdyX> But as it is for us; comprehensive communication is _hard_ and takes time.
19:18:28 <bremner> ack
19:19:22 <bremner> is the understanding about not embedding libraries somewhere in policy?
19:19:37 <bremner> (aside from rules about package names for shlib packages)
19:19:52 <OdyX> #info https://wiki.debian.org/EmbeddedCodeCopies
19:19:57 <marga> This issue is not about embedding libraries, though
19:20:00 <fil> also, I'd imagine they may be wary of giving detailed explanations to nitpickers
19:20:04 <OdyX> 4.13.
19:20:11 <OdyX> fil: oh sure.
19:21:05 <bremner> marga: do you have a one sentence summary of what this is about? I remember finding the original report pretty incoherent
19:21:29 <ntyni> "it's not about code copies. but about adding additional binary packages just to avoid one dependency"
19:21:30 <fil> saying to someone "Rejected for reason X" where X is the most egregious of 7 reasons, is liable to get people claiming that not that X is fixed, all must be fine
19:21:51 <fil> s/not that/now that/
19:22:05 <bremner> ntyni: ah right. so this is about ftp-masters preference for not having too many small packages
19:22:12 <ntyni> yes I think so
19:22:25 <OdyX> and node/ruby crossover?
19:22:44 <marga> Ok, my understanding is that this is about a library (? not sure if one file or more) that can be both used by Ruby and by nodejs and so the maintainer decided to ship the package split into separate pieces, once with a dependency against Ruby and the other with a dependency against nodejs.
19:22:45 <bremner> OdyX: sure, but I guess that's just because of extra dependencies?
19:23:16 <ntyni> marga: that matches my understanding
19:23:39 <bremner> and the stated reason for reject is "don't have so many small binary packages"
19:23:40 <marga> The rejection is that these two packages are too small and the split is thus not justified
19:23:48 <fil> yup, in order to avoid dragging in ruby when only needing nodejs, or vice versa
19:24:11 <marga> Right.
19:24:30 <bremner> I don't really agree with the emphasis on avoiding small packages, but I do think it is ftp-master's call
19:24:47 <OdyX> It's also the tip of the "node produces trillions of tinybitsy packages" problem.
19:24:54 <bremner> ack
19:25:03 <bremner> but in other places small packages seem harmless
19:25:04 <marga> Right, I guess if node wasn't involved it would be a different story
19:26:01 <fil> in this particular case, I'd quite like to see it demonstrated that there are any real users that actually care if they get nodejs and/or ruby cluttering up their system
19:27:29 <bremner> I forget why these things need to be dependencies and not recommends?
19:27:48 <marga> packaging policy apparently (I'm re-reading the bug)
19:28:01 <OdyX> because one of the shipped binaries then doesn't work out of the box?
19:28:04 <OdyX> (in some cases)
19:28:11 <bremner> yeah, well, devscripts
19:28:14 <marga> Like all ruby library packages should depend on the ruby interpreter.
19:28:27 <bremner> ok, but that's team policy, not Debian policy
19:28:28 <marga> And the npm2deb tool creates packages that depend on nodejs
19:28:43 <marga> Sure
19:28:44 <bremner> even weaker IMHO
19:29:10 <ntyni> they probably need parts of the standard library shipped with the interpreter
19:29:27 <bremner> need for what though?
19:30:39 <ntyni> in the Perl world lib*-perl do things like 'use strict' that are provided by the Perl standard library
19:30:50 <ntyni> I imagine it's similar for Ruby; node is a different beast of course
19:31:18 <marga> Yeah, so in Ruby all ruby libraries depend on the interpreter, while for node it's less homogeneous
19:31:31 <bremner> ntyni: sure, but this is only a failure mode if there is a binary shipped. Pure library packages (obviously?) don't need to depend on interpreters
19:31:42 <bremner> byte-compilation would be an exception
19:32:04 <marga> So, this package could just recommend nodejs, but then the issue is that those that only want to use the node part of the library need to install "ruby | ruby-interpreter, ruby-rack, ruby-activesupport, ruby-html-pipeline"
19:32:18 <fil> there'a also the thing that one can want the library because one is throwing it a browser to be run, rather than running it locally
19:32:19 <bremner> well, those could be recommends too
19:32:54 <marga> Well, not if they are really necessary for the ruby part
19:33:03 <ntyni> bremner: I'm saying if the library requires parts of the standard library and the standard library is shipped with the interpreter, a Depends seems appropriate
19:33:17 <bremner> well, not if it creates bugs that escalate to the TC
19:33:24 <marga> I mean, I do think it would be annoying if I was trying to use the library to have to differentiate between two different recommends.
19:33:43 <bremner> In practice you would already have node installed if you needed it
19:33:49 <bremner> similarly for ruby
19:34:02 <marga> Well, but not necessarily ruby-activesupport, whatever that does
19:35:08 <marga> If I was the maintainer of this package, I'd opt to keep the ruby deps as Dependencies and the nodejs dep as Recommends (because it's just nodejs, AFAIU), but I do see the point of this being not-ideal.
19:35:12 <bremner> yeah, maybe there is some hidden reasons, but I'm seeing a conflict between ruby team policy and ftp-master, it it's clear who wins there
19:36:15 <marga> I'm not sure I see that conflict, bremner
19:36:45 <bremner> I guess the dependency is more complicated on the ruby side.
19:36:52 <marga> This whole issue is because there's a source package that ships both a ruby and a nodejs library, which is not what the policy is about
19:37:16 <bremner> yeah, but the "must depend on ruby" thing is a ruby team decision
19:37:40 <marga> Yeah, but I'm inclined to think that makes sense.
19:37:51 <bremner> maybe I'm in the minority then
19:38:12 <bremner> I don't understand how missing depencies on interpreters are a problem in practice
19:39:09 <marga> Yeah, you might be right about the interpreter, but what about the other libs?
19:39:47 <bremner> I _guess_ those are not such heavy dependencies
19:40:00 <marga> how so?
19:40:15 <bremner> most libraries for interpreters are small
19:40:32 <marga> Ah, you mean in size
19:40:42 <marga> I thought you meant in how necessary they were
19:40:55 <bremner> ah, no, quite the opposite.
19:41:00 <marga> Yeah, ok, they're probably less relevant in the "pull in useless stuff" part
19:41:09 <fil> I think it only becomes a problem when one zealously implements the policy about binaries working out of the box, and then rubs up against the ftp-masters too-small-package thing -- it would be perhaps important if people were using this to reimplement grep in nodejs, say, such that everything broke when removing nodejs.  I don't think that's our reality.
19:41:37 <bremner> well, yes, binaries are a problem.
19:42:44 <marga> Anyway, it doesn't seem like we're getting anywhere...
19:43:41 <OdyX> Should we be asking d-policy and ftp-master to work on a saner policy there?
19:44:06 <bremner> OdyX: what could change from a policy point of view?
19:44:16 <OdyX> Or just defer it to ruby and node communities to get together for something meaningful?
19:44:45 <bremner> OdyX: you mean put "don't depend on interpreters unless you really need them" in policy?
19:45:08 <OdyX> bremner: clarify which types of binaries should work directly, and which could be allowed to require recommends (sic)
19:45:15 <bremner> ah, OK.
19:45:47 <bremner> sounds like a potential policy bug. and maybe not that controversial?
19:46:03 <marga> What would the bug be exactly?
19:46:39 <bremner> please clarify when it's OK for binaries not work without recommends?
19:46:50 <bremner> I mean, that's already a kind of judgement call.
19:47:41 <OdyX> a non-0 exit with a meaningful stderr message would work for me.
19:47:43 <marga> Wait, but THIS bug is about a library, and the binary thing was about a package that ended up being accepted?
19:48:22 <bremner> well, if it's about a library than I guess _my_ recommendation is don't depend on interpreters
19:49:03 <marga> So, the policy bug would be about not depending on an interpreter for a library?
19:49:34 <bremner> could be. Or we could just issue that as advice.
19:49:53 <bremner> unless it's crazy advice, of course.
19:49:54 <marga> Given that none of us is an expert on Ruby (AFAIK), I think it would be good to have input from the ruby team on this.
19:50:22 <marga> But in his first mail, smcv said that all python and perl packages also do this
19:50:33 <marga> s/packages/library packages/
19:51:01 <ntyni> indeed
19:51:10 <marga> So, why is that?
19:51:28 <bremner> it's generally a harmless dependency
19:51:48 <ntyni> in the case of perl there's the perl-base/perl split so you could have /usr/bin/perl installed without the full standard library
19:52:16 <ntyni> not sure if that's the main/only reason though
19:52:47 <ntyni> it's a very long standing tradition
19:52:59 <bremner> yeah, that's not _totally_ convincing ;)
19:53:32 <ntyni> you're not convincing me that it's wrong either :)
19:53:47 <bremner> well, it manifestly causes problems in this instance.
19:53:52 <bremner> IIUC.
19:54:16 <bremner> it's a weird case, and maybe it's silly to have policy machinery about it.
19:54:30 <marga> So, could we issue advice that says, "stop depending on interpreters that you don't use"?
19:55:01 <marga> I mean, it would make zero difference in this case, because of all the ruby deps, that would need to all stop depending on ruby
19:55:28 <ntyni> yeah that's a good point
19:55:33 <bremner> Or we could, as you say, ask the ruby team why they do this.
19:56:14 <marga> Ok, do we want to take an AI?
19:56:17 <ntyni> and perl and python etc. before issuing such a general statement
19:56:36 <bremner> ntyni: do you feel qualified to answer the perl case?
19:57:27 <ntyni> not sure
19:57:32 <ntyni> I think raising this on -devel might be good
19:57:47 <ntyni> this == libraries depending on interpreters
19:57:50 <bremner> ok
19:58:11 <marga> Yeah, I think that makes sense
19:58:22 <marga> Is there anybody who'd like to take this?
19:58:47 <bremner> I probably can't in the next two weeks.
19:59:05 <bremner> at least, not and pay any attention to the answers
19:59:08 <marga> The AI would be to start a thread on -devel asking whether it still makes sense for libraries to depend on interpreters, if they don't include binaries.
19:59:28 <bremner> but I can do that before next meeting if noone else wants the honour
19:59:28 <ntyni> I'll take that
19:59:32 <bremner> yay!
19:59:49 <fil> I'm not sure that's the exact problem that is ending up in this beffudled case though -- there's also the stuff about depending on multiple interpreters when as few as zero of them might actually be needed for a particular use case
20:00:38 <marga> #action ntyni to start a thread on -devel asking whether it still makes sense for libraries to depend on interpreters, if they don't include binaries.
20:00:44 <marga> Thanks Niko :)
20:00:45 <ntyni> fil: I agree it's more complex than that
20:00:58 <bremner> fil: sure, but if we can't answer the simple question...
20:01:03 <bremner> which seems of general interest
20:01:14 <marga> Alright, we're over time and it seems that we've reached a good ending point.
20:01:27 <OdyX> Somehow yes.
20:01:28 <marga> #topic Any urgent other business?
20:01:39 <fil> well, as long as answering the simple question isn't taken as some sort of answer to the mess ;-)
20:02:03 <OdyX> Recruiting ? Mithrandir and myself are leaving in 2.5 months, this time for reaz
20:02:05 <OdyX> realz
20:02:10 <marga> Yeah :(
20:02:42 <marga> The tricky thing is that we've been thinking about a reform. But I guess we should start our recruiting campaign anyway
20:02:50 <bremner> yes
20:03:01 <OdyX> Or reform now and recruit differently later.
20:03:02 <fil> is your departure not somewhat like brexit?  or ist it really happening this time?  ;-)
20:03:07 <bremner> I mean, disbanding the TC is one way of solving the recruiting problem
20:03:27 <bremner> seems a bit lazy of us though
20:03:40 <OdyX> fil: unless we vote a GR before Dec 31, it's a hard Mithrandexit and Odyxit yes
20:04:02 <marga> I guess I'll take the AI to send the email that I was going to send last year when I realized that the calculations had been wrong.
20:04:16 <marga> We still need to think about the other issue.
20:04:19 <OdyX> (no hard bord^W feelings though :P )
20:04:44 <marga> #action marga to send mail about recruiting
20:04:59 <marga> #endmeeting