18:59:32 <marga> #startmeeting
18:59:32 <MeetBot> Meeting started Wed Aug 21 18:59:32 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:38 <marga> #topic Roll Call
18:59:51 <marga> Who's here?
18:59:51 <Mithrandir> Tollef Fog Heen
18:59:52 <marga> Margarita Manterola
18:59:54 <gwolf> Gunnar Wolf is here
18:59:59 <fil> Philip Hands
19:00:52 <marga> OdyX? You said you'd be here?
19:00:53 <OdyX> Didier Raboud
19:00:57 <marga> Ah, there :)
19:01:13 <OdyX> Present and mostly focused.
19:01:20 <marga> #topic #932795 How to handle FTBFS bugs in release architectures
19:01:40 <marga> So, Gunnar reached out to the Release Team about this 10 days ago.
19:01:50 <marga> gwolf, did you hear anything about it?
19:01:51 <gwolf> I expected to see more movement on this bug... but it seems it does not inspire much communication by anybody :-(
19:02:10 <gwolf> I got a private mail from a RT member stating his opinion
19:02:37 <OdyX> could we get it on our alias (from that person) ?
19:03:05 <OdyX> It seems like a classical "TC cannot override a delegate" case, right?
19:03:19 <gwolf> I will obscure the person and send it to ctte-private - In short, it says it "makes sense", but he fears the team is a bit overworked with arch qualification
19:03:36 <gwolf> But he mentions RT has a meeting on 2019-08-28, and they can discuss the issue
19:03:41 <gwolf> (will ask him to do so)
19:03:47 <OdyX> So unless RT asks the TC to rule, we can't say much more than "hmm yeah, it seems it makes {,no}sense"
19:04:04 <gwolf> right. Just give our opinion on the thing
19:04:58 <marga> Agreed
19:05:07 <Mithrandir> we can also decide to set technical policy here by (*handwave*) requiring packages that do not build on $standard_machine to declare so in a suitable format in the control file.
19:05:33 <marga> In which suitable format?
19:05:36 <gwolf> (oh - I'm sending it unobscured - he *did* mean to send it to our public list, sorry)
19:05:49 <Mithrandir> that'd need to be further defined, but not by the TC, since we don't do that.
19:05:58 <marga> I think this would actually be going down the road of designing...
19:06:36 <bremner> I think there is a broader social issue about bug severities and RC bugs in particular.
19:06:49 <bremner> not sure if we're the right body to address that issue.
19:07:00 <Mithrandir> I'm not sure we want to go down that route, on one hand, having it explicit if packages have unusual requirements would be good, on the other hand, lots of work, and it'll be useless unless it's actually used.
19:07:15 <Mithrandir> (that route = the one I'm handwaving about)
19:07:27 <gwolf> bremner: I think we are *not* the right body. But a general answer, we can give.
19:07:50 <marga> Right, I think this might actually be an interesting thing to specify. But I don't think it's up to us to do so...
19:07:52 <OdyX> I haven't followed closely, but, provided we don't have a mechanism for packages to specify their minimal requirements (minCPU: 2), building in otherwise fine environments (chroot, etc) that just have 1 CPU available seems reasonabl.
19:08:31 <gwolf> It could be right for packages to specify any "oddities" of its build - but it opens a can of worms. What can be specified? What not?
19:08:37 <OdyX> bremner: but then who is? Not the Policy editors, not the DPL; the RT ?
19:09:07 <Mithrandir> is this something the community team should be involved in?
19:09:18 <gwolf> You know my opinion - I think it should be up to the RT to define the minimum expectations. But, yes, that's something they should first accept
19:09:35 <marga> Uhm, I don't think their responsibilities are well defined, but I don't think that's in their scope
19:09:52 <OdyX> So GR ?
19:09:59 <bremner> marga: it's a refinement of definining release architectures
19:10:13 <Mithrandir> marga: their = who? CT?
19:10:18 <bremner> I mean, if what vector instructions are allowed is valid, I think #cores also is
19:10:21 <marga> I meant the community team in my comment, sorry
19:10:28 <OdyX> and they drop architectures when "they can't keep up" over time
19:10:37 <marga> I do think this falls onto the release team to define what's supported
19:10:56 <bremner> more broadly, it's up to the release time what is "release critical"
19:11:01 <gwolf> OdyX: Why GR?
19:11:04 <marga> But I don't know who's responsibility it is to define how to specify oddities
19:11:21 <bremner> and this bug was essentially about the submitter wanting a bug to be RC
19:11:24 <Mithrandir> marga: nobody's really.  Somebody who's interested.
19:11:32 <OdyX> gwolf: it would allow to avoid picking a team to have to decide on that, an provide a clear path forward.
19:11:58 <gwolf> Well - mips is getting dropped because the architecture is no longer technically able to build many packages (FSVO many) with <2GB per process - That's arch qualification.
19:12:10 <Mithrandir> I think we're discussing multiple things here: the social bits, how to work around the underlying bug with technical measures and who decides what when it comes to RC-ness
19:12:17 <OdyX> gwolf: "We collectively decide that it's a bug worth fixing when packages don't build with $blabla"
19:12:21 <Mithrandir> and having all those discussions interleaved is confusing.
19:12:26 <bremner> agreed
19:12:31 <gwolf> Defining minimum thresholds per architecture does not seem too taxing for me - but I'd like to hear explicitly from the team before we pass the ball to them
19:12:32 <OdyX> ack
19:12:33 <bremner> social issues first?
19:12:38 <Mithrandir> bremner: sgtm.
19:13:05 <bremner> FOAD, QA work is important, and underappreciated
19:13:18 <gwolf> OdyX: hmm... GR seems not-nice in my book. Maybe as the TC we can make a call to RT to state after their meeting whether they can take this?
19:13:37 <gwolf> And if not, well, it becomes An Issue™
19:13:44 <Mithrandir> gwolf: GRs don't solve social issues, let's keep to that first.
19:13:48 <gwolf> right.
19:14:09 <bremner> so, what are the social issues?
19:14:14 <OdyX> and past efforts that started as mere QA (amd64, reproducible, …), have proven their usefulness later
19:14:26 <bremner> right.
19:14:27 <marga> The social issue I think is QA work not being appreciated?
19:15:28 * ntyni waves, sorry I'm late
19:15:57 <gwolf> marga: Yes. The hostility in the original bug report was quite unwarranted, FWIW. I didn't feel any kind of understanding was attempted.
19:16:18 <marga> Right, I agree with that. But I'm not sure how we could solve it
19:17:01 <bremner> We maybe can't solve it, but it might help to publically affirm the value of QA work as something the project should care about.
19:17:19 <bremner> I think that is technical policy if you squint right
19:17:26 <OdyX> There's a point about "which QA", isn't it?
19:17:32 <bremner> of course.
19:17:34 <Mithrandir> I'm not sure the maintainer saw this as QA work.  At some point you go from QA to pushing the envelope on what a reasonable build env looks like in order to file more RC bugs, so it depends a bit on point of view.
19:17:59 <bremner> Mithrandir: OK. Is that an independent social problem?
19:18:35 <OdyX> I think we can certainly agree that "QA merits our consideration, as do QA-related bugs"
19:18:39 <bremner> Mithrandir: also, I think assuming good faith comes in here
19:18:54 <marga> Mithrandir, while that could be the case, I think that's not the case here, so probably not worth discussing hypothetical cases.
19:18:57 <gwolf> But it could be argued that "QA work should not be done on impossible situations"
19:19:10 <gwolf> Because for one of the parties, single-core building is an impossible situation
19:19:58 <OdyX> And we _do_ have lower limits for other things: disk, RAM.
19:19:59 <gwolf> So, this could be rephrased on whether it is really a QA effort or a relic from the past or whatever... Not all QA efforts are valued equal :-\
19:20:14 <Mithrandir> bremner: I don't know if it's the case here.  I genuinely believe that one side did not see this as useful QA work, at least initially.
19:20:40 <marga> Yes, agreed.
19:20:43 <bremner> Mithrandir: I know, but I think that was the wrong way to approach it.
19:20:54 <marga> Ok, so, what do we want to do about this?
19:21:03 <OdyX> I personally find value in the essence of the single-CPU setup: it's a simple model.
19:22:25 <gwolf> I also sympathize with the position arguing for single-CPU being workable.
19:22:30 <gwolf> However, that's not for us to judge
19:22:36 <gwolf> We cannot qualify it as enough or not
19:22:37 <OdyX> on the other hand, testing software "Algorithms for Parallel Adaptive Mesh Refinement" on multi-CPU, makes sense.
19:22:55 <bremner> OK, but can we finish the social question first?
19:23:30 <gwolf> bremner: What would solve it? Us agreeing to issue a call for recognizing QA work, in the abstract?
19:23:43 <OdyX> Sure, although it's related: these models and how they're communicated also have social effects.
19:24:01 <bremner> or recognizing work that crosses the boundaries of individual packages or teams.
19:24:05 <Mithrandir> should the submitter have a way of tagging a bug "this is part of a QA effort", in order to hopefully let the maintainer know that while a setup might seem slightly contrived, the submitter has created that setup to increase quality?
19:24:26 <bremner> Mithrandir: a usertag?
19:24:31 <Mithrandir> (and so hopefully build more empathy for qa efforts over time)
19:25:05 <Mithrandir> maybe a usertag would be useful, yes, or a real tag?
19:25:12 <bremner> yeah, either way I guess
19:25:15 <gwolf> Ummm, while Lucas had his daily rebuild project going, all mails included something similar to what Mithrandir suggests - and it helped quickly understand what was going on
19:25:21 <OdyX> If it's a serious bug, it will trigger the whole autoremoval process.
19:25:25 <gwolf> So, yes, it could be a recommendation for this case as well
19:25:54 <bremner> 1) QA good. 2) explain you're doing QA
19:25:55 <marga> Yeah, I guess we could recommend an introduction to bugs explaining that this is part of an ongoing QA effort and then invite everybody to recognize that QA efforts make our codebase better
19:26:10 <OdyX> with or without usertags. That's also the social discussion: are all FTBFS serious?
19:26:11 <Mithrandir> recommend that QA efforts set up a wiki page explaining what they do and include that link in bug reports would also work.
19:26:15 <marga> I don't know how much we would solve, but I guess we can do that.
19:26:44 <marga> OdyX, I don't think that's a social issue
19:26:54 <bremner> or at least it's a different one
19:26:57 <marga> I think that's the part that's left to the RT
19:27:03 <OdyX> indeed.
19:27:23 <OdyX> but the severity of the bug being serious is what makes the odds higher.
19:27:24 <gwolf> yes
19:27:41 <gwolf> I agree with the interpretation that RT defines which bugs are RC
19:27:46 <OdyX> And doing QA that results in packages removed from a release is harsh.
19:27:55 <OdyX> So perhaps "do QA as important bugs" ?
19:28:38 <bremner> Generally I think being conservative with bug severities is sensible. OTOH, some things are clearly RC.
19:28:42 <Mithrandir> "think about whether you think your QA effort, even if it leads to FTBFS bugs, should lead to the package failing the QA test to be removed from the next stable release"
19:29:01 <OdyX> ^ thanks for the phrasing.
19:29:12 <gwolf> Mithrandir: <clap><clap><clap>
19:29:49 <fil> quite -- one seems very likely to get a significantly more negative reaction if firing off a lot of bugs that are going to remove packages
19:30:19 <marga> Ok, it seems we have consensus on this?
19:30:28 <bremner> I'd like to "both-sides", and add something like "as a maintainer, consider whether such a bug makes your package unfit for the stable release"
19:30:50 <Mithrandir> bremner: yup!
19:30:55 <OdyX> +1
19:31:00 <gwolf> Right. In this case, that addresses the social issue.
19:31:13 <marga> Ok, we need to action someone to send that email, I guess
19:31:21 <marga> Anybody feels like volunteering?
19:31:38 <gwolf> Well, I took action on this bug earlier on
19:31:43 <gwolf> I can take it again
19:31:47 <marga> Ok :)
19:31:54 <Mithrandir> are we doing this as a recommendation with a resolution or just issuing some informal guidelines?
19:31:55 <gwolf> I will draft it and send it to the private alias
19:32:10 <ntyni> fwiw I think the submitter has stated clearly that he thinks all FTBFS bugs should be RC, presumably with all the consequences including removal
19:32:13 <gwolf> I think it would be a way of non-ruling but issuing a general recommendation
19:32:36 <ntyni> so I'm not sure how much that recommendation helps
19:32:39 <bremner> Mithrandir: I think resolution needs RT input?
19:32:47 <marga> #action gwolf to write an email with the agreed consensus regarding explaining QA efforts, recognizing QA efforts, considering whether this should be RC from the QA point of view and the maintainer point of view.
19:32:49 <OdyX> 6.1.5 Offer advice; if phrased well enough.
19:32:56 <ntyni> (but I certainly agree with the proposed recommendation)
19:33:09 <gwolf> I still hope RT will discuss the issue...
19:33:25 <marga> Right, do they need any kind of input from our side?
19:33:26 <bremner> should we mention that we think the specific decision is up to the RT? do we agree on that?
19:34:04 <OdyX> In our "advice" decision? I'd avoid pressuring them through it.
19:34:07 <Mithrandir> yes, they decide whether packages are fit for the release or not, by way of RC-bugginess, which in theory is decoupled from bug severities.
19:34:24 <marga> Yeah, agreed
19:34:33 <fil> yes, I agree
19:34:33 <gwolf> lets say it's loosely coupled :-]
19:34:38 <ntyni> agreed
19:34:41 <smcv> sorry, only just got here
19:34:49 <Mithrandir> and by extension, I think they should also decide if bugs filed by a QA effort are RC or not.
19:34:58 <marga> Ok, are we done with this bug or is there anything else that warrants discussion here?
19:35:10 <bremner> Mithrandir: yes, I think that's implicit
19:35:29 <smcv> I think part of the issue with this particular QA bug-filing is that the bug submitter wants his bugs to be RC to force people to fix them
19:35:33 <bremner> Mithrandir: but I'm happy to be explicit if you think it helps
19:35:38 * gwolf quickly jumps to search for coffee
19:35:54 <smcv> and I don't think that's OK - RC status is a tool for producing working releases, not a stick to hit maintainers with
19:35:57 <Mithrandir> bremner: probably more implicit than by extension, I agree. I think being explicit here could be useful, since we are being asked about this particular angle.
19:36:06 <OdyX> smcv: yes.
19:36:12 <fil> smcv: quite
19:36:17 <ntyni> smcv: yes, I also think there's a "stick" part that I'm uncomfortable with
19:36:21 <marga> I would prefer not to judge the motivations
19:36:39 <marga> And rather stick with our recommendations, which I think that are sensible.
19:36:39 <bremner> smcv: I agree also. That was my original comment about "general problem with bug severities and RC bugs"
19:37:14 <bremner> smcv: I think the bug submitter is far from alone in feeling that way about RC bugs.
19:37:32 <smcv> I think QA is important, and it's good for people to do it, but they should not expect that every bug they find gets prioritized highly
19:37:45 <bremner> we don't seem to have any other levers to convince people that our priorities should be other people's priorities.
19:37:54 * gwolf agrees with general sentiment on RC-stickiness
19:37:55 <bremner> remember release goals?
19:38:07 <Mithrandir> smcv: agreed, and it can change over time.  reproducible builds started out as a pet project and is now rather important.
19:38:16 <bremner> Mithrandir: but still not RC
19:38:35 <marga> I think this is not going anywhere productive, can we move on to the next topic?
19:38:40 <bremner> ok
19:38:56 <marga> #topic #934948 Unnecessary dependencies vs multiple binary packages
19:39:30 <marga> Alright, so I really liked Simon's elaborate response to this one, but it only happened today
19:39:39 <gwolf> smcv: Thanks for your summary on this one. Really helped me understand the issue better than a casual read while tired.
19:39:58 <OdyX> thanks indeed.
19:39:59 <fil> smcv: yeah, that was great, thanks
19:40:36 <fil> so we're waiting on the reply to that now?
19:40:39 <smcv> having spent an hour earlier today trying to describe the problem, I still don't have a solution
19:40:55 <ntyni> there's a reply already
19:40:58 <gwolf> marga: Yes, it only happened today - But it feels we will (again) end up deciding "hey, that's not for us to decide"
19:41:05 <ntyni> Date: Wed, 21 Aug 2019 22:59:50 +0530
19:41:08 <gwolf> We cannot overrule a delegated body (ftp-masters)
19:41:11 <bremner> gwolf: that was part of the setup
19:41:16 <gwolf> yes
19:41:25 <marga> Well, they explicitly asked for advice
19:41:55 <gwolf> oh, was it them that asked Praveen to open the bug? Right...
19:42:04 <bremner> I don't see the reply
19:42:07 <smcv> I don't think so?
19:42:21 <marga> No, Praveen opened the bug asking for advice
19:42:32 <marga> ftp-master just told them not to do what they were doing.
19:42:33 <gwolf> The original bug report mentions, "I was also told to contact CTTE and DPL before going for a GR by js team members."
19:42:52 <marga> Ah, yes, although I didn't see that in the chat log
19:43:29 <bremner> smcv: so if there was no executables involved, just dropping the depends on nodejs would be fine, right?
19:43:36 <smcv> I can't help thinking that was less "hmm, we don't know, ask the CTTE" and more "stop talking to us, please talk to someone who is not us, and if you *really* think we are wrong, the bureaucratic way to overrule us is a GR"
19:44:03 <smcv> possibly with an implied subtext of "don't open a GR" that Praveen missed
19:44:42 <smcv> bremner: as far as I can work out, nothing would fail without the dependency? so yes?
19:44:59 <smcv> libraries for interpreters that don't depend on their interpreter feel a bit weird
19:45:07 <ntyni> would alternative dependencies be a viable compromise? Depends: nodejs | ruby
19:45:17 <Mithrandir> sounds like a textbook use case for Recommends, tbh
19:45:20 <smcv> but maybe only because I'm used to Python which is needed at install-time to byte-compile
19:45:29 <bremner> smcv: fwiw, emacs addons work that way (no dependency on emacs, if done correctly)
19:45:43 <OdyX> smcv: it's not _needed_, but better, is it not?
19:45:54 <marga> I'm not sure where the rule of having to depend on the interpreter comes from
19:45:57 <ntyni> on the perl side I think libraries having Depends: perl is more for the standard library than for /usr/bin/perl
19:46:06 <smcv> if you think "this is like libfoo-perl" then Depends makes sense
19:46:11 <gwolf> (looking at the packages in question)... I don't think a general case can be made out of this - as this is quite clearly tied to the two ecosystems in question (ruby and node)
19:46:19 <smcv> if you think "this is like openarena-data" then Recommends or no relationship at all makes sense
19:46:33 <smcv> either mental model can work here, I think
19:46:42 <OdyX> and JS can be useful without an interpreter (served to browsers).
19:46:45 <smcv> right
19:46:46 <Mithrandir> there's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517
19:47:17 <OdyX> so "any JS that is useful when served accross network should not Depend on a local interpreter" ?
19:47:17 <gwolf> Part of the argument was that the js bits were usable from a browser (which completely escapes our packaging ecosystem
19:47:19 <gwolf> )
19:47:43 <Mithrandir> gwolf: to me, that suggests that the relationship to nodejs should at most be recommends.
19:47:46 <bremner> I think "not useful without the interpreter" is not a problem the package system needs to solve
19:47:55 <bremner> I mean, nodejs uses will have nodejs installed.
19:48:04 <OdyX> gwolf: not completely; we (or "some") want to be able to ship full web applications from Debian packages"
19:48:07 <marga> Yeah, I actually agree that if the file is usable without the interpreter, the interpreter doesn't need to be in the Depends field, it could be Recommends or even Suggests.
19:48:20 <marga> But of course, this is a case by case thing, not something that will match all packages
19:48:42 <bremner> I don't even think it needs to be usable in an obvious way. Maybe the user has a private copy of nodejs
19:49:03 <gwolf> bremner: You could also say that installing a Ruby library without Ruby installed is agreeable because you want to be able to open it locally with Emacs to study it
19:49:08 <OdyX> I'm quite biased also because I've come to be used to having perl and python2 on virtually all systems.
19:49:15 <marga> Uhm... I'm not sure that's a valid argument. You could make it for python interpreters as well.
19:49:21 <gwolf> it is not the use case Debian works with...
19:49:34 <smcv> python is different because the postinst runs pycompile
19:49:47 <smcv> so it literally won't install correctly without a python interpreter
19:49:59 <OdyX> … which makes things faster, but is not _mandatory_.
19:50:00 <smcv> (won't configure, in dpkg-speak, iirc)
19:50:06 <bremner> well, in the case of executables, the harm of a missing interpreter is clear, since the user doesn't need to know what interpreter it uses
19:50:14 <bremner> I just want my frobnicator.
19:50:27 <marga> You are right. But the point is that in general we want our packages to be usable inside Debian, not with outside packages
19:50:40 <Mithrandir> bremner: yup, but even that is allowed to be non-Depends for non-core bits of the package.
19:50:46 <smcv> right, if you install the package that provides /usr/bin/frobnicator, and it happens to be written in nodejs, and it doesn't have Depends: nodejs, then you will be sad
19:50:57 <smcv> at least if it's the frobnicator package in Section: utils
19:51:18 <smcv> if it's the node-frobnicator package in Section: javascript that arugument is weaker
19:51:44 <bremner> marga: the harm of the extra depends is larger than the (hypothetical?) harm of the missing depends, unless the install breaks or something similar
19:51:55 <bremner> smcv: my technical view on sections is that they can die in a fire
19:51:58 <bremner> ;)
19:52:03 <marga> what's the harm of the extra depends?
19:52:06 <smcv> bremner: sure, but they're a convenient way to make my point
19:52:08 <gwolf> ... This still feels at very least that a Recommends would be in place
19:52:14 <bremner> marga: getting nodejs when you don't want it
19:52:20 <gwolf> marga: bloating your install by ~50MB for node
19:52:27 <marga> 50MB
19:52:28 <marga> Ok.
19:52:29 <smcv> bremner: "this is the package for a utility" vs. "this is the package for a Javascript library"
19:52:31 <fil> marga: pulling in an interpreter one has no intention of ever using
19:52:36 <gwolf> (didn't check for Ruby)
19:53:26 <Mithrandir> Ruby seems smaller, but we're looking at 15+MB at least.
19:53:38 <Mithrandir> so it's not huge, but also not tiny.
19:53:47 <bremner> plus security surface in both cases
19:53:48 <fil> (assuming that's a real subset of our users)
19:54:29 <OdyX> The question asked to FTP is #921628 "Allow creating separate binaries for node and browser environments when the node component provides and executable"
19:54:34 <smcv> the fact that one of praveen's example packages is a mixture of ruby and javascript seems particularly odd, but I suppose that's a combination that makes sense to Ruby-on-Rails programmers
19:54:34 <gwolf> (ufff, most of nodejs' dependencies size is taken by libicu64 - 32MB... International Components for Unicode :-P
19:55:03 <bremner> OdyX: yes, it would have helped for Praveen to summarize that bug.
19:55:31 <bremner> and that goes back to my original question about executables being the problem.
19:55:41 <smcv> OdyX: so for the "provides an executable" case, which is actually not the one where Praveen is asking us to not-really-overrule-but-sort-of-overrule the ftp team, I would automatically have said
19:55:48 <Mithrandir> smcv: a lot of CSS/JS related stuff seem to be nodejs, so there's some crossover there. I've seen a bit of the same in the Rust world.
19:55:55 <smcv> move the dotted line into a different place
19:56:13 <smcv> instead of: nodejs stuff | browser stuff
19:56:19 <smcv> have: library | executable
19:56:40 <smcv> and then it becomes obvious that the executable needs a dependency on its interpreter, and the library doesn't
19:56:41 <marga> smcv, can you clarify? I'm not sure I see what you mean
19:56:50 <OdyX> From the py and pl examples, it seems harsh to special-case js on the interpreter question. Put I have yet to see a web dev using nodejs from Debian, nor expecting to have nodejs without installing it explicitely.
19:57:13 <smcv> so for example src:tap.py (which I maintain) has these binary packages
19:57:17 <smcv> python3-tap - a library
19:57:26 <smcv> python-tap - a library
19:57:51 <smcv> and tappy - /usr/bin/tappy (which, behind the scenes, is a CLI wrapper around python3-tap)
19:58:34 <smcv> following the general principle of packaging the executable as though it's an executable, and the library as though it's a library, and those are different things
19:58:46 <OdyX> currently the interpreter is a depends of python{,3}-tap, and not of tappy
19:58:47 <marga> And how would that look like for the node package?
19:59:12 <OdyX> move the nodejs depends to tappy, away from libjs-tap ?
19:59:16 <smcv> node-frobnicator (also Provides: libjs-frobnicator) - a library
19:59:46 <smcv> and frobnicator (exists to supply /usr/bin/frobnicator) - an executable, which happens to depend on nodejs and node-frobnicator
20:00:04 <marga> But would the ftp team allow this?
20:00:11 <smcv> that's the question
20:00:12 <OdyX> ah, that's where things become scary; thanks for the highlight.
20:00:17 <smcv> they did for tappy
20:00:45 <bremner> smcv: yes, but you didn't submit 7000 packages of that form
20:00:49 <gwolf> right, but the JS team happens to have a ton of tiny packages
20:00:52 <smcv> I had thought that it was best-practice to package executables to look like executables, and libraries, separately, to look like libraries, if you see what I mean
20:00:53 <gwolf> right
20:01:12 <bremner> smcv: agreed with the best practice part.
20:01:27 <smcv> as opposed to for example libaudio-mpd-perl, which I happen to have installed solely because it contains /usr/bin/mpd-dynamic
20:01:34 <OdyX> actually, both tappy and python3-tap Depends: python3:any
20:01:49 <smcv> (and I keep accidentally removing it when I mark all of Section: perl as "automatically installed")
20:01:52 <OdyX> (be
20:01:57 <marga> Yeah, but we already mentioned that python libraries need the intepreter to run postinst
20:01:58 <gwolf> (It's been 1hr... And I have to leave, sorry ☹ )
20:02:01 <OdyX> (because pycompile)
20:02:04 <marga> yeah, we're overtime
20:02:11 <marga> Is there an action to take here?
20:02:15 <gwolf> I will look at backlog in a couple of hours, and probably comment off-meeting-time
20:02:31 <OdyX> (yeah. Sorry, I'm very tired and need some repeating to understand stuff tonight)
20:03:09 <smcv> can I continue to brain-dump a bit and give people something to think about offline?
20:03:16 <fil> so, this is all to avoid a dependency that pulls in ~50MB when it might be on a web server that wants to serve it to clients, is that right?  ... and there are web servers that might not have 50MB spare presumably.  Hmm
20:03:32 <Mithrandir> yes please. I don't think we're ready to rule on this.
20:03:39 <gwolf> FWIW, I think this issue makes perfect sense for ftp-masters to decide
20:03:40 <OdyX> It seems to me that Pirate's cause could benefit from having a Coach/mentor to help phrasing things clearly too.
20:03:47 <Mithrandir> fil: I'm vaguely worried about container use case, not really machines.
20:03:47 <smcv> for the 7000-packages-like this situation, I wonder whether the answer is to aggregate some of the JS libraries into fewer larger packages that "look like a library"
20:03:54 <gwolf> And I'm leaning towards "the ctte supports ftp-masters' decision"
20:04:07 <marga> #action smcv will continue brain-dumping and share with us.
20:04:08 <gwolf> but yes, it's a bit too quick to decide - my brain is more hungry than clear
20:04:09 <bremner> smcv: they already have something like that going on, but I think you know?
20:04:09 <marga> Thanks Simon!
20:04:14 <smcv> and aggregate some of the executables that happen to have been written in JS into fewer larger packages that "look like executables" (in the style of libglib2.0-bin)
20:04:15 <fil> Mithrandir: ah, fair enough
20:04:18 * gwolf leaves now. o/ !
20:04:29 <marga> And we'll close it here, we didn't get to discuss re-thinking the TC. We'll do that next time
20:04:33 <marga> #endmeeting