18:58:59 <silwol> #startmeeting
18:58:59 <MeetBot> Meeting started Wed Aug 26 18:58:59 2020 UTC.  The chair is silwol. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:08 <silwol> Welcome everybody!
18:59:14 <kpcyrd> hi!
18:59:22 <hntourne> Hello
18:59:36 <silwol> #topic agenda
18:59:48 <silwol> I created a wiki page at https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda for collecting the agenda topics.
19:00:47 <silwol> My idea is that we collect the topics between the IRC meetings.
19:01:24 <wookey_> just made it
19:01:27 <silwol> I simply created it in the debian-conf namespace, not sure it's exactly the best place.
19:01:34 <silwol> welcome wookey_
19:02:30 <silwol> any input on this topic?
19:03:06 <wookey_> which topic?
19:03:21 <wookey_> where to put the agenda?
19:03:27 <silwol> exactly.
19:03:58 <wookey_> I'd use the debian wiki rather than the salsa wiki for this sort of thing
19:04:11 <wookey_> but I don't suppose it matters much
19:04:11 <silwol> silence is consent ;-)
19:05:23 <silwol> for me it doesn't matter. I didn't think about the debain wiki as I don't use it that much, the thought was more whether the debcargo-conf namespace is the correct one.
19:05:33 <silwol> but debian wiki is a good idea also.
19:05:46 <wookey_> I'd expect that to be about debcargo-conf package
19:05:58 <wookey_> the debian wiki is the right place for info not specific to packages
19:07:25 <silwol> it mainly is, but we'll probably also touch other relate topics in the future.
19:07:52 <silwol> I think we'll leave it as is for now, except if somebody comes around with a proposal.
19:08:04 <silwol> #topic status updates on the topics from the previous meetings
19:08:11 <wookey_> if you are used to using salsa to organise the team then putting all the info on salsa makes sense I guess.
19:10:00 <silwol> I contacted the golang team and asked for the information about working on a repository for build-time deps only.
19:10:34 <silwol> they already had a bug report on which people from our team commented that weren't present on the previous meeting.
19:10:56 * silwol looks up the bug no…
19:11:12 <stappers> #idea dedicated Salsa project for  orga stuff  as an agenda
19:11:43 <silwol> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949163
19:12:42 <silwol> I didn't get around to contact any of the other teams as mentioned in the todo.
19:13:27 <silwol> kpcyrd: you mentioned you were in contact with kali people, would you like to talk a bit about their stance?
19:16:36 <kpcyrd> yes, hold on
19:20:30 <f_g> here (better late than never ;))
19:20:46 <silwol> welcome f_g
19:21:28 <wookey_> you've not missed much :-)
19:21:35 <eriol> I'm here too... sorry for being late!
19:21:55 <silwol> welcome eriol
19:23:13 <silwol> while we're waiting for kpcyrd's report, I can in the meantime tell that I didn't manage to contact f_g, so no process on creating the feature-collapsing PoC :-(
19:23:39 <f_g> indeed. been busy with non-Debian stuff like vacation ;)
19:24:10 <f_g> there has been 'progress' by the way of lots of REJECTs, and the BoF today though.
19:24:24 <f_g> so maybe a report from that would be interesting for those that missed it?
19:25:09 <silwol> f_g we have that on the list, we're currently wrapping up the status of the todo list from the previous meeting.
19:25:19 <f_g> ack
19:25:23 <silwol> (I updated https://salsa.debian.org/rust-team/debcargo-conf/-/wikis/IRC-Meeting-Agenda accordingly ;-) )
19:25:29 <capitol> my take on the BoF: we didn't really have that much of solutions in the BoF, it was more that people shared their frustrations and got to meet eachother
19:25:54 <capitol> oh, sorry for going out of turn :)
19:26:02 <kpcyrd> got a call, be back in a few min sorry
19:26:31 <silwol> maybe we should talk about the debian-rust mailing list topic?
19:27:21 <silwol> stappers: you wrote to the listmasters, would you like to report what the status is there?
19:28:15 <stappers> The sad news is there is nothing to report.
19:28:44 <stappers> Listmasters didn't yet respond.
19:29:06 <stappers> In attempt the break the silence
19:29:36 <silwol> +1
19:29:43 <stappers> I did invite listmasters to attend this IRC meeting  ( silwol  had CC ( yesterday ))
19:29:53 <hntourne> stappers: do you have the needed advocacy for the request? If I recall well you mentionned 2 DD should be "supporting" the request
19:29:56 <silwol> I read that. Not sure any is present.
19:30:21 <wookey_> I'm a DD
19:30:28 <eriol> I'm a DD too
19:30:34 <wookey_> hapy to support the idea that rust should have a mailing list
19:30:45 <eriol> me too of course
19:30:48 * stappers is not sure about the minium DD count for a new ML
19:30:48 <wookey_> surpried you don;t have one already!
19:31:06 <silwol> wookey_: we do, but  it has a difficult-to-remember address, and is spammed by package upload messages.
19:31:08 <f_g> wookey_: there is an alioth one that is the maintainer address
19:31:30 <silwol> we'd like to have debian-rust@, but keep pkg-rust-maintainers@ for the package upload messages.
19:31:41 <wookey_> right. makes sense
19:32:07 <wookey_> that's where I just looked, to see no list :-)
19:32:15 <stappers> eriol: wookey_  please use your "DD status" on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966088
19:32:53 <wookey_> Will do
19:33:00 <stappers> :-)
19:33:13 <eriol> sure! :)
19:33:41 <silwol> #todo eriol wookey_ write support e-mail to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966088 bug
19:34:03 <silwol> anything else open from the to-do list?
19:34:33 <hntourne> stappers: https://www.debian.org/MailingLists/HOWTO_start_list - says that it s appreciated if other shows shared interest - does not seem mandatory but can't harm :)
19:34:45 <f_g> infinity0: wanted to write a TCTTE draft AFAIR
19:36:13 <wookey_> OK. bug mailed
19:38:06 <silwol> f_g seems the item didn't land on the todo list, so no idea whether the idea was to write a draft already.
19:39:30 <wookey_> I guess that's related to the NEW/debcargo/crates issue which we'll no doubt get to shortly
19:40:15 <silwol> kpcyrd: should we proceed to the next topic and you tell your report later?
19:40:23 <f_g> silwol: see 21:40:58 ff from last log
19:40:32 <kpcyrd> I'm back
19:40:41 <silwol> cool!
19:41:10 <kpcyrd> ok, so kali would like to ship rust software, but they would prefer something that's simpler than what we're currently doing (until the software landed in debian proper, at which point they would drop their package)
19:41:54 <silwol> do they have any plans to implement something by their own?
19:43:03 <kpcyrd> they are still looking for an approach that builds offline, now I'm wondering what's the easiest way to 1) take the upstream tar ball 2) populate it with cargo vendor 3) repack it as tar ball and proceed with regular debian tooling
19:43:31 <kpcyrd> for the 3rd step I'm lacking knowledge about how to do that with debian tools
19:43:56 <f_g> kpcyrd: you could look at what src:cargo does in Debian
19:44:05 <f_g> (not src:rust-cargo !)
19:44:11 <kpcyrd> and I'm not sure what's the right channel to get support, #debian-devel is probably just for debian specifically
19:44:17 <kpcyrd> f_g: good hint, thanks!
19:44:52 <wookey_> dpkg-source will repack a debian source tree
19:45:13 <wookey_> that might be what you are looking for
19:45:37 <f_g> it's basically what we do for cargo the binary package, vendor all the crates it depends on so that we don't have the cargo <-> debcargo-conf bootstrapping problem
19:46:38 <kpcyrd> sounds great, I'm going to look into that and ask in #debian-rust if I'm stuck :)
19:47:11 <f_g> https://salsa.debian.org/rust-team/cargo/-/blob/debian/sid/debian/scripts/debian-cargo-vendor
19:48:05 <silwol> It looks like I'll have to leave in about 20mins.
19:48:27 <wookey_> dpkg-source -x package.dsc, add crates, dpkg-source -b <directory containing source>
19:48:50 <kpcyrd> we can proceed to the next topic!
19:49:11 <silwol> #topic summary of the BoF earlier today.
19:49:35 <silwol> who would like to give the summary?
19:49:59 <wookey_> you were there :-) and knwo what's what :-)
19:50:12 <silwol> I tried my best.
19:50:38 <silwol> but it's difficult for me to summarize.
19:50:52 <silwol> of course the main topic was the ftp/binpackage problem.
19:51:59 <wookey_> I think we found that FTPmasters (at least according to Waldi, and no others came despite being given opportunity)
19:52:25 <wookey_> really are no longer going to accept the existing debcargo scheme
19:52:42 <wookey_> So we can:
19:52:46 <capitol> yeah, they were quite clear on that
19:52:48 <wookey_> 1) give up a go home
19:52:55 <wookey_> 2) change to some other mechanism
19:53:02 <wookey_> 3) take it to the technical committeee
19:53:38 <wookey_> It ewas good to have some go people present as they are in a similar situation
19:53:54 <wookey_> but have chosen a more conventional packaging system
19:54:22 <silwol> I assume the go people don't have the problems in the same way we do, as the go bulid system doesn't support features from what I can tell.
19:54:36 <wookey_> Agreed - there are technical differences
19:54:59 <wookey_> which I have not yet grokked
19:54:59 <silwol> What we have in common is the static-lib issue though.
19:55:07 <silwol> or better, static-compilation.
19:55:43 <silwol> from what I assume the issue is that debian is mainly designed to work well with shared libs, and reflects that in the packages.
19:56:18 <capitol> the debian security team had a question on how we track security issues in crates when everything is statically compiled, and I think our answer was that we don't
19:56:25 <wookey_> we talked about mechanisms to do rebuilds when there are updates to libraries
19:56:29 <silwol> if you find a security issue for example, you fix that, and as long as no ABI-incompatible changes were made (which rarely is necessary for that type of problem), you just replace the affected lib with a fixed version.
19:56:50 <capitol> that would be an nice thing to work on at some point in the future
19:56:59 <f_g> capitol: you basically re-compile leaf packages that ship binarys that are built-using the affected library crate
19:57:01 <silwol> with our packaging scheme, we upload source code into binary packages, so once we update a lib, we have to recompile the affected bin packages.
19:57:03 <wookey_> capitol: right, and it's not unreasonable to ask that we make one
19:57:05 <f_g> but no automation for that yet
19:57:22 <capitol> f_g: yes :)
19:57:58 <silwol> is that a solved issue in golang? it seemed to me that they don't have a solution to that eiteg.
19:57:59 <silwol> either.
19:58:15 <wookey_> silwol: yes I think they are looking for something too
19:58:49 <f_g> in the trivial/API compatible case its a grep on build info + schedule bin-NMU
19:59:03 <wookey_> It was noted that the haskell team have a system, but that is tpo deal with the fact the the abi for everything changes when the compiler is updated
19:59:13 <wookey_> which is a bit different
19:59:20 <f_g> in the non-trivial case, it's the same as for shared libs that break ABI in a security fix, look at the breakage, fix it, do an upload
19:59:37 <f_g> wookey_: rust is the same, which is why nobody does shared linking
19:59:43 <silwol> I think a shared solution between the teams - or one that is similar in handling by the security and release people - would help here.
20:00:02 <silwol> (so rather package metadata than anything rust-specific)
20:00:14 <wookey_> f_g: right, I see. so we _could_ do that, at the cost of having to rebuild _everything_ on a regular basis
20:00:26 <capitol> we could pull security information from: https://github.com/RustSec/advisory-db/
20:01:00 <f_g> wookey_: in theory yes. in practice, there are a few road blocks to even do that ;)
20:01:23 <wookey_> f_g: OK, what is the problem?
20:01:39 <silwol> capitol: https://github.com/RustSec/cargo-audit might help here as well.
20:01:52 <f_g> I don't have the details handy, but a colleague did an attempt at shared linking at work and there were quite some more caveats beside the whole 'toolchain update invalidates all the built binaries/libs'
20:02:24 <f_g> IIRC something regarding the std lib, and intra-crate linking
20:02:39 <wookey_> I saw something about symbol mangling. I need to investigate/understand this
20:03:23 <silwol> I talked to efraim (rust-guix, was in the bof today) in person after their rust presentation on fosdem, they have similar problems.
20:03:43 <wookey_> The current security assumption is that it only needs to be fixed in one place, and that package gets fixed, re-uploaded and built
20:04:15 <wookey_> that's not really true because we already have embedded libraries so somtimes more than one thing needs to be fixed/uploade/rebuilt
20:04:23 <silwol> true, and in our scenario we have the additional point "find all affected leaf packages and rebuild them as well".
20:04:23 <f_g> yes, but they already needed some mechanism/tooling for go for Buster IIRC
20:04:31 <wookey_> the number just rises for statically-linked things
20:05:18 <f_g> yep. and it's mostly automatable (as in, a script that gives you all the packages needing a rebuild/bin-NMU given a fixed lib crate package)
20:05:20 <wookey_> seems to me that fixing this for the general case in the tooling that the security team use would be a good plan
20:05:58 <f_g> a generic one that detects whether the fixed package is a go/haskell/rust/.. package and then runs the appropriate lookup over build info is probably a good idea
20:06:13 <f_g> first step would be to ask them whether they have anything like that already that could be extended to support rust
20:06:42 <wookey_> some tool that knew how to follow the build-deps/build-info/built-with metadata for various languages and schedule/order builds/binnmus as required would make a lot of people happy
20:07:28 <silwol> does any of these metadata sources already contain everything required?
20:07:57 <wookey_> I presume that the necessary info can be extracted, but I don;t actually know.
20:08:16 <wookey_> The catch is having to grok 8 different languages and their tools :-)
20:09:06 <f_g> IMHO the bigger question is how to proceed w.r.t. ftp-masters and debcargo
20:09:27 <eriol> I remember this tool for Go: https://tracker.debian.org/pkg/ratt but I don't know if it covers the security related use case. I used Go several years ago, but never used it.
20:09:54 <siretart> I've been using that tool successfully recently
20:09:59 <silwol> f_g yes, that's currently the most pressing issue to unblock.
20:10:13 <siretart> it uses dose to calculate reverse dependencies and then invokes sbuild to build each of them
20:10:35 <wookey_> I was going to say that dose can probably help us work out the deps
20:11:00 <capitol> should we make a list of people that want to look at the security tooling problem and continue to the ftp-master problem?
20:11:09 <capitol> I have to leave soon also
20:11:18 <capitol> I'm willing to be on that list
20:11:37 <wookey_> Sure
20:12:17 <wookey_> the security thing is important, but not as urgent as 'our whole language is blocked until we think of a new plan'
20:13:19 <wookey_> I think we have to decide if we want to fight or acquiesce
20:13:33 <capitol> just to throw something radical out there: could we vendor all dependencies instead?
20:13:52 <silwol> capitol: `cargo-deb` ;-)
20:14:17 <wookey_> capitol: you mean put all the deps in the source of each rust package?
20:14:22 <f_g> #topic debcargo future / ftp masters rejects
20:14:38 <silwol> not sure the security team would be happy about that, I think it would be too easy to overlook vendored crates.
20:14:54 <f_g> capitol: I don't think either ftp-masters or security would be happy about that approach
20:15:05 <f_g> see discussions about kubernetes a few months back on -devel
20:15:28 <f_g> it also scales rather badly when more and more tools written in rust get packaged
20:16:00 <silwol> plus you'd have many libs in different versions.
20:16:02 <f_g> (if you don't want to drop all pretense of packaging the deps sanely, e.g. try to avoid duplicate versions, vendored bindings, ...)
20:16:02 <capitol> so they want one package per crate, but not our current solution for features
20:16:06 <wookey_> I'm up for doing some analysis on the current situation and what happens if we collapsed all the features
20:16:38 <wookey_> which seems to be the main sticking point
20:16:42 <f_g> capitol: not necessarily. e.g., the JS team sometimes bundles small modules into a single source+bin package
20:17:04 <f_g> but yes, they don't like that we ship many empty binary packages
20:17:15 <silwol> #todo silwol still would like to work on adding the feature-collapsing to debcargo.
20:17:20 <f_g> they also don't like that we do a lot of provides encoding semantic version info in the provided package name
20:18:04 <f_g> both would be reduced if we don't enable all features by default
20:18:59 <silwol> f_g do you think some kind of "whitelisting" for features, or simply patching out everything we don't need?
20:18:59 <f_g> but both would only go away completely if we don't automatically convert the info from Cargo.toml to d/control, but instead specify it manually on a case-by-case basis
20:19:53 <f_g> IMHO a map of {"bin_package_a" -> ["feature_1", "feature_2"], ...} would be the most sensible middle-ground approach
20:19:54 <wookey_> f_g: yes, but that's what packaging is.
20:20:47 <wookey_> It's nice to have totally automatic packaging from upstream's module system, but sometimes that doesn;t really make sense, or upstream's sysem is just to crazy to map into a distro well
20:21:17 <wookey_> We only have to do it once for each package, don't we?
20:22:19 <wookey_> (sorry if I'm asking dumb questions here - I'v enot yet taken the time to propoerly understand this stuff)
20:22:22 <silwol> what if we default to collapsing all features in a package with a specific naming scheme? it would help us to find and exclude features that miss dependencies, and it would only require work on packages that depend on such packages that were not collapsed.
20:22:34 <silwol> (thus saving us from polluting the provides lines)
20:22:51 <f_g> wookey_: you'd have to do it for both sides of the dep relation if you do it fully manually
20:23:05 <f_g> and upstreams basically change/add/remove feature every second patch release for some crates
20:24:02 <f_g> rust makes up ~4% of source packages in main, I think it would not be very feasible to have this kind of overhead for packaging lib crates
20:24:17 <f_g> a single binary can easily have hundreds of transitive dependencies
20:24:55 <wookey_> f_g: if we add metadata to a package to conflate features, why can' tthat metadata be used automatically by things that depend on the package?
20:25:18 <wookey_> i.e why do we have to 'do both sides manually'?
20:25:46 <f_g> because debcargo as a standalone tool does not know/care about the current instance of debcargo-conf
20:26:06 <f_g> so it would not know where to find that information
20:26:15 <f_g> it operates on a single crate at a time
20:27:29 <wookey_> Does anyone think that in fact debcargo is just the right way to do this and the FTPmasters are wrong to reject it?
20:27:52 <wookey_> i.e we should write a complainto the technical committee?
20:28:02 <f_g> infinity0 definitely does ;) they're also the main author of debcargo :-P
20:28:50 <f_g> I think debcargo works quite well, but I can understand some parts of the criticism. it's rather different from most other packaging approaches
20:28:50 <capitol> I haven't understood if we are running into some sort of technical limitation, or if it's just someone who thinks it's ugly
20:29:26 <silwol> I don't have very strong opinions on that. I have been maintaining an in-house repo with a major part of the crates for some time, and it worked really well.
20:29:27 <wookey_> ah yes, one other thing of significance from the BoF. When asked about 'why are we going through NEW', FtP masters did sort-of agree that if there was a reliable way to distinguish being 'real NEW' and 'NEW that should be autoaproved' then maybe that could be done
20:29:34 <f_g> I think it's mainly an argument of 'this is a waste of resources'. both human (bin-NEW triggers ftp master reviews) and machine (bigger Packages files -> more parsing overhead -> ...)
20:29:50 <silwol> but we have the shared resource "package index", and from that pov I understand that there are some issues.
20:30:54 <silwol> wookey_: according to waldi they basically have that reliable way, but they decided that rust isn't worthy of getting access to it :-)
20:31:13 <wookey_> So it may be worth pushing the idea that manual NEW review could be skipped in specific circumstances, if we could reliably define those
20:31:47 <wookey_> silwol: hmm, that's not what I understood from what was said. I thought he said there was no such mechanism
20:32:08 <wookey_> (implying that if there was a mechanism they were happy with, then maybe it could be done)
20:32:23 * stappers was not at the BoF
20:32:41 <silwol> as I said earlier, I assume that waldi's position may not be same as the one of the majority within the ftpmasters team, but that's just my impression from the outside.
20:32:41 <f_g> wookey_: it would basically be 'auto-approve bin-NEW for librust-.*+.*-dev'
20:32:50 <stappers> Which other FTP masters beside Waldi did speak?
20:32:57 <f_g> as those are always empty semantic packages atm
20:33:16 <silwol> stappers there was a general invitation addressed to the ftpmasters team, but only waldi showed up.
20:33:28 <wookey_> f_g: but those packages are actually 'genuinely NEW' on initial upload
20:33:34 <stappers> chips
20:33:43 <silwol> If I understood it correctly waldi said they have such a mechanism, but it's more targetted towards kernel packages et al.
20:34:11 <silwol> f_g but 'genuinely NEW' is also triggered on new source packages, right?
20:34:22 <wookey_> silwol: yes
20:34:22 <f_g> wookey_: no, on first upload rust-* is NEW
20:34:45 <f_g> on a 'new/renamed/...' feature upload, only librust-.*+.*-dev are bin-NEW
20:34:51 <wookey_> OK. I see what you mean. Should work
20:35:13 <silwol> and the non-features bin package which is built from every rust source package would also be new on the first upload.
20:35:21 <wookey_> Waldi claimed to speak for all ftpmasters on this. We don;t know if that's really true
20:35:35 <wookey_> But I have no reason to doubt it
20:35:55 <f_g> but such an auto-approve would just solve our problem of long bin-NEW wait times
20:36:08 <f_g> it does not remove the concerns about the index/Packages file
20:36:14 <wookey_> f_g: exactly
20:36:20 <wookey_> IMHO that matters
20:36:22 <f_g> and it's unlikely we get such an auto-approve before we managed to clear those concerns
20:37:05 <f_g> so it's back to square one - do we want to attempt CTTE to get a third opinion on whether our usage of Packages to encode semantic information is okay
20:37:28 <f_g> and if no, or if yes and it fails, how do we reduce the number of things we encode there
20:37:49 <f_g> 1.) don't package all features, but only a sub set that is explicitly specified
20:38:12 <f_g> 2.) don't split binary packages by feature (sets), unless explicitly specified
20:38:23 <f_g> was what I proposed back in the salsa issue
20:38:32 <f_g> I'd possibly even add
20:39:11 <f_g> 3.) don't encode semantic versioning information in provides, instead implement a mechanism to map package names in rdeps to support the rare case of multiple lib crate versions in one release
20:39:23 <f_g> then we can instead do plain versioned build-deps
20:39:42 <wookey_> This is the way I would try to go if it was up to me.
20:40:22 <f_g> the first two would work simply on the rdep side, the third one would need to be done on both sides of the packaging equation, but is/should be a rather rare occurrence
20:40:40 <wookey_> as I put in the etherpad, we currently have 14,148 binary package from 767 source packages
20:40:48 <wookey_> that's excessive IMHO
20:41:30 <f_g> yes, and lots of features that are no used by any rdeps, but it's hard to tell how many of those are just unused because stuff that would use them is not yet packaged/did not make it through NEW (yet)
20:41:40 <wookey_> 18 binaries per package
20:42:27 <silwol> that seems more than I would assume from my experience working on the packages.
20:42:44 <f_g> I'd also say that there are some false positives or some massive outliers in there
20:42:45 <wookey_> I'd also push back upstream on the static/dynamic thing. People are ARM are doing this too
20:42:48 <silwol> are these true bin packages, not provides?
20:43:10 <wookey_> silwol: not sure - I did some quick apt-cache grepping last night
20:43:49 <wookey_> I don;t think apt-cache shows virtual provides, but it may show non-virtual provides. I forget the details
20:43:52 <silwol> if the provides were included the number would be around what I'd expect.
20:43:58 <f_g> I count ~1700 bin packages in main, for ~800 source packages
20:44:39 <f_g> (via grep-dctrl | sort -u | wc -l, so might have some noise in it as well)
20:44:43 <wookey_> OK, that sounds a lot better
20:44:53 <wookey_> It was 2am :-)
20:44:57 <silwol> thats nearer to what I'd expect.
20:46:06 <silwol> so basically, that number could be reduced to match nearly the number of source packages, and the provides could possibly removed if we didn't encode the semver information in our version numbers, right?
20:46:14 <wookey_> that 14,000 is from apt-cache dump | grep librust- | grep Package: | sort | uniq | wc
20:47:49 <silwol> yes, that includes provides at a quick glance.
20:47:59 <wookey_> OK.
20:48:30 <wookey_> silwol: ISTM that the semver info should only be encoded in package names when you need to have more than one in the archive at once
20:48:53 <f_g> wookey_: or not even then, you just need to tell the rdep to explicitly depend on the older package
20:49:01 <silwol> yes, I also think it is the exception to have more than one version.
20:49:02 <wookey_> for that vast majority of packages where 'latest' will do it's not needed
20:49:21 <silwol> From the design it looks to me as if it was intended to provide smooth migration to newer versions.
20:50:12 <silwol> I also think the package name without the version number in the name was not there from the beginning, but got introduced at a later point.
20:50:39 <wookey_> right. I saw some debate about that in a bugrep
20:50:46 <f_g> yes, the current mechanism allows to upload a crate B that depends on crate A ver X
20:50:58 <silwol> so all packages were intended to look like librust-rand-0.6-dev, but that was in the time before the first crate packages got uploaded to the archive.
20:51:09 <f_g> and even if we later upload crate A in ver Y, and re-upload crate A-X for version X, the old built crate B is still vaid
20:51:47 <f_g> the new mechanism would require a rebuild of crate B with a flag to encode the version X of A in the dependency package name
20:52:44 <f_g> which is okay, as that is supposed to rarely happen, and if it does, it's a simple rebuild without any other changes
20:52:48 <silwol> I worked on the rand 0.6 to 0.7 migration some time ago, and the main blocker was getting 0.6 through NEW before updating the non-version-named package to 0.7, just to have the 0.6 packages removed afterwards.
20:53:13 <f_g> silwol: even more reason to make that a rare exception ;)
20:53:33 <silwol> I also think if we make the parallel version installable package the exception this increases the pressure on us to push upstream.
20:54:16 <wookey_> It seems to me that we may be reaching a consensus amongst those present on the direction to take?
20:54:32 <wookey_> BUt we may get disagreement from those not [present
20:54:57 <silwol> true. so how do we proceed on this topic?
20:55:04 <wookey_> all this still requires someone to do some work
20:55:43 <silwol> infinity0 expressed thy would take a look at the MR if we proposed one.
20:55:45 <wookey_> If we had a mailing list, I'd say a summary to the list :-)
20:55:55 <f_g> wookey_: silwol and me already volunteered trying a PoC for debcargo last time, we just didn't do it yet. I am not that familiar with CTTE and policy to weigh in whether we want to go down that route
20:56:10 <silwol> I'd be willing to work on debcargo, but I can't promise I'll be able to invest a lot of time, so help would be welcome.
20:56:51 <silwol> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers for now.
20:56:56 <wookey_> I think the action is to look seriously at what a new scheme would look like
20:57:21 <wookey_> what that does to the number of packages and provides and circular dependencies
20:57:28 <eriol> I just don't know if I would able to work on something like this, but as I said I changed job to have more time, so I can help here if someone can mentor me.
20:57:35 <f_g> I'll try to find some time in the next 2 weeks to start on the feature/bin-package filtering feature and flesh that out more as well
20:57:57 <f_g> I think the version thing is fairly straight-forward, it's mostly dropping or selectively disabling certain code paths
20:58:04 <wookey_> I have some expertise in dependency analysis, but very little in debcargo yet
20:58:27 <wookey_> Last 3 weeks I have done nothing but wall insulation :-)
20:58:39 <f_g> wookey_: I think the main issue is that it's hard to estimate what the additional work load to think about and manage those feature sets will be
20:58:46 <capitol> I have to leave, I'll read the rest of the meeting tomorrow
20:58:48 <f_g> but it might be that we don't have a choice anyway
20:58:54 <wookey_> I put last board up 3 hrs ago, so when I go back to work I can spend some time on this
20:58:56 <silwol> bye capitol
20:59:04 <eriol> bye capitol!
20:59:49 <wookey_> Thanks for a productive discussion.
21:00:08 <silwol> f_g is it ok for you to contact me when you want to work on this? I usually have my day off on fridays, and when school starts again, it will be easier to allocate that for whatever I want.
21:00:36 <silwol> apart from that, evenings are ok as well most of the time.
21:01:14 <silwol> I imagine I could start hacking, but I'm sure I would miss many edge cases and ideas you already thought about.
21:01:29 <f_g> yes, sure :) will probably end up being the first week of school anyway ;)
21:02:20 <silwol> #todo f_g silwol hack on feature-collapsing in debcargo (again ;-) )
21:02:34 <f_g> for real :-P
21:03:01 <silwol> ok, so I think we'll leave this topic for now. feels like we're making some progress.
21:03:32 <silwol> #topic overview page for packaging
21:04:14 <silwol> I stumbled over https://go-team.pages.debian.net/ some days ago, and found that a really great entry point for people new to a team.
21:04:47 <silwol> I think we should put the idea of creating something similar on our radar.
21:05:03 <silwol> (no immediate action required, just wanted to drop it so it's seen by others).
21:05:23 <silwol> that's all from my side.
21:05:36 <silwol> any other topics?
21:05:57 <wookey_> not from me
21:06:16 <f_g> silwol: looks similar to the wiki.d.o page: https://wiki.debian.org/Teams/RustPackaging ;)
21:07:04 <silwol> basically yes, but more structured and better-looking.
21:08:31 <f_g> :D
21:08:37 <silwol> although I'd say our page contains much more detailed information than required for a newcomer. I also really like the short list of helpful links for daily packaging tasks that is easy to spot.
21:08:57 <f_g> would not hurt for sure, just needs to be kept updated as well..
21:09:10 <f_g> (I don't have any other topics either btw)
21:09:22 <silwol> ok, then I'd say we close the meeting.
21:09:28 <silwol> thanks everybody, see you next time!
21:09:32 <silwol> #endmeeting