Removal of a package

[vrurg]

I can't find a way to remove accidentally uploaded module version from the ecosystem. Even though Cro::RPC::JSON 0.1.904 has production: false in its META, zef upgrades to the version implicitly.

[tony-o]

Thinking through this. We already have a lot of issues reported where people can't install modules because something happened in p6c user removed their dist|user renamed a dist|user broke some piece of the dist off into its own dist and now the dependency doesn't find the new dist because it's provided by what's installed. There's more. I'm wondering if maybe patching a dist should be allowed within an hour of uploading.

I don't know what production: false means or why that's relevant.

EDIT: I bring up the information in the first paragraph because I'm curious what your thoughts are on solving the problems created by removing modules.

[vrurg]

I don't know what production: false means or why that's relevant.

https://design.raku.org/S22.html#production

Perhaps fez should give a BIG warning if the key is present and it is false.

Talking about my case, I have accidentally published a version from development branch which number actually obsoletes any production version on the same branch. I.e. dev numbers in my model are x.y.9xx, and production are x.y.[1..899]. So, I effectively disabled the whole 0.1.xx.

Perhaps pulling out a single version should be possible because the worst case would then be if there is a dependency recorded for exactly this particular version which is rather unlikely.

Alternatively, zef must not allow installation of non-production versions without a special request.

Otherwise I'm not sure I can be really helpful with packages as I'm don't have that much experience with the kind of issues you mention. Technically I can only think of a full indexing which will know everything about dependencies. And since we're basically out of control of CPAN and, up to some extent, of the ecosystem repo, we barely can do much about any changes done do them. On the other hand, fez technically can find out if a module being removed has any dependents and take corresponding actions.

Yet, it's rather questionable what kind of actions these could be. It just crossed my mind that we actually don't have any kind of license agreement with module publishers. What is the actual ownership of the module when it's published? One of the targets of fez development, as you declared, is to provide authors with better protection over their modules. But how far does this go? Shouldn't the right to remove be considered a part of this protection? I'm not sure.

[tony-o]

That is technically a pretty good point - i'll manually remove that module for now and implement the warning on the client side. Fez only looks at the dist info (of which production isn't). It's going to take me a little bit to figure out dependency chaining to ensure no deps are broken by removal.

[vrurg]

Turns out I overlooked the fact the the dev version was actually in the LocalCache. I confused it up with a neighbor version from Zef::Repository::Ecosystems<fez>. Anyway, the mistake has led to a good discussion. :)

[tony-o]

@vrurg - i'm on the fence about time vs dependency. otoh you can be reasonably sure no one has pinned a module within an hour but you can't be reasonably sure you're not removing a module that broke backcompat.

[vrurg]

I tried to think over it, but not sure I consider all possible options. First of all, I'm not sure that ecosystem must maintain integrity by disallowing module removal. There're too many other ways to break things down and wether is makes sense to try to block one of them is still not clear to me.

Yet, what if a severe security issue has been discovered in a module? Releasing a fix and removing the bad version sounds like the best option. If there is another module which depends on the removed one then it wouldn't be affected unless it's dependency points at that particular vulnerable version. In this case I'd rather consider sending a warning email to the author.

Alternate solution is a bit more complicated. If we know that there is a strict version dependency then removal may require to specify a replacement. I.e. x.y.1 is unsafe, but x.y.2 is fixed. So, the index will contain a "redirection". Whenever x.y.1 is requested x.y.2 will be installed instead.

One last option just have came into my mind. A version could be disabled, not removed. In this case it remains available for installation with a kind of --force CLI option when absolutely necessary. But otherwise it must have a description of reason for disabling and the reason would be displayed to the one requesting the version.

[tony-o]

@vrurg branch eco_rmdist introduces a way to remove a dist from the ecosystem. currently doing some testing and the rules around it right now are: must be removed within 24 hours of upload.

[tony-o]

This feature is introduced with d39800a

[vrurg]

I better avoid testing the feature these days. So, if anything pops up in the real life – I'll report with a new issue.

BTW, support for production key will is likely to be even more useful for me.

Thank you!

[tony-o]

@vrurg ive been chatting with nick about how tiers or some other way of managing strict vs not strict auths could work and support for production will likely come with that. Once that’s in place it’ll also lend itself to hosted dark ecos