tonyo wonder, what is meant by take back? 03:34
jjatria Thanks lizmat 09:05
13:49 coleman left, coleman joined 16:05 sjn left
tonyo okay the stats has been caught up for a few days and it looks like the job is running well every two hours 17:56
tbrowder__ still seeing dups on 19:43
tonyo jjatria++ love 19:48
tbrowder__ but what causes the dups? 19:56
tonyo: showing bailador (and maybe panda) as popular seems to show the need for some way to tag obsolete or otherwise not-to-be-listed modules in such places as 20:00
Bailador closed its doors years ago 20:01
lizmat tbrowder__: please report any dups that you see 20:20
20:22 lizmat left
tbrowder__ *Santagata 20:29
22:28 sjn joined
jjatria This is a hard problem to solve, because they are not really duplicates: the duplicate author, for example, links to and Those are two different auths, so for Raku their distributions are different, even if they have the same name 22:46
Unless we have a way to mark auths as being logically the same, we cannot do much other than eg. drop CPAN 22:47
But even then, as desirable as that might be, that doesn't really solve the problem, because this is by design: Raku is designed to support multiple ecos 22:48
So even if we drop CPAN, there'll still be GH. And even if we only keep zef, the problem will be the same when zefpp (or whatever) comes around 22:49
sjn why not just interprete the ecosystem name (e.g. "zef:" or "cpan:") as a namespace, and make a required part of the name?
… make it* a …
also, on that note, have had a look at the PackageURL spec? 22:51
… have you* had …
jjatria But what would that solve? Because there's nothing stopping me from creating `zef:sjn` (if that doesn't already exist), even if `github:sjn` does 22:53
And then how can we tell that those belong to the same person?
Re. PackageURLs I did! It'd be nice to add those to RL 22:54
I think, at least. I haven't seen that much discussion on that over on this side 22:55
sjn well, if you have to have names represent the same person across ecosystems, then I think the solution would have to include a way to ensure that one namespace is fully subservient to another. (e.g. the authority of "sjn" comes from the github account)
this can be done by requiring login to the zef publishing infrastructure only using github accounts 22:56
jjatria Right, but I don't think the "multiple ecosystem support" design ever really considered the possibility that there would be a "canonical" ecosystem that all the other ones would refer to 22:57
sjn jjatria: about PackageURLs, see for work on getting support for this into CPAN
jjatria That feels like a pretty big design change. But if that feature existed, we could use it in RL 22:58
Until then, I'm not sure how much RL can do about this problem... :|
sjn jjatria: yeah, that's the problem with namespaces - either you have to allow for different people with the same id in different ecosystems, or you have to derive authority somehow 22:59
jjatria We have thought about the possibility of some sort of internal RL-specific user-management, but it's nice that we don't actually keep any user data (means there's nothing for us to leak), so we'd rather not have to go that way
sjn the simplest is to accept the discrepancies, but make it visible in the tooling that there may be sources of confusion 23:00
jjatria For context: this has come up in the past:
sjn yeah 23:01
Another option (which would probably be useful wrt. the upcoming EU laws regarding supply chain security), would be to introduce ways to cryptograhpically verify authors, and then use this information to merge package entries that are published on different channels 23:03
personally, I think that would be fantastic, and probably the best solution to this problem 23:04
though not the easiest one to implement :-D
one way to do it, is to upgrade the META6.json spec to something that contains the necessary information for creating SBOM documents, and then find a way to cryptographically sign these 23:07
we're having discussions around these topics in the #cpan-security channel nowadays, and with FOSDEM getting a Perl & Raku devroom next year, there's a really good motivation to come to some decisions on this there, at least 23:08
(feel free to join the channel & discussion if these topics interest you! :-D) 23:09
jjatria I'm planning to attend FOSDEM, so it'll be interesting to see what comes up then :D 23:12
sjn sweet! 23:13
there's an SBOM track too, plus a track on the EU legislative landscape (which I expect to share a lot of info on supply chain-related laws coming in 2024), and a track on identity and access management... :-D 23:15
jjatria re. your idea about author verification, etc: that's the kind of thing that cannot be implemented in RL (since we consume ecos, we don't manage them), but that if implemented RL can definitely use
I've been keeping my eyes peeled for the CfP for the Perl & Raku devrooms, but I haven't seen anything yet 🍿
sjn jjatria: remember, as a consumer, you can set expectations :-D
jjatria: CfP is being prepared as we speak, and should be out (hopefully) tomorrow 23:16
jjatria sjn++
sjn discussions are ongoing in the #fosdem-organisers channel on the TPRF slack 23:17
(happy to invite you there, if you care and have calories to spare :-D) 23:18
jjatria Ah, I had joined plain #fosdem 😅 23:25
I feel like I'm already stretched a little thin, but I'm happy to lurk 23:26
lizmat how about adding a "superseded" field to the META6.json that would be added by the author to the old distribution (e.g. on CPAN) with the auth of the new dist ? 23:34
superseded-by 23:35
and/or have a list in the ecosystem repo with mapping from old to new 23:37
sjn that would probably work great in addition to author verification 23:38
another (softer) option would be a "preferred-ecosystem" or "primary-ecosystem" field, that could have values like "zef", "cpan" and "git" 23:39
a third option (which maybe already is supported? I don't know) may be to just allow the author to specify a primary ecosystem namespace 23:42
that might create some lock-in issues for the ecosystem providers, should the need to move/rename (though I guess that's unlikely) 23:43
jjatria lizmat++ 23:58
I think even if not to solve this particular issue, the `supersedes` fields and friends are a neat idea I miss from the META spec 23:59