Ability to orphan packages

[Stebalien]

It would be nice to be able to orphan/abandon libraries.

1. Building a crate that depends on an orphaned library would emit a warning.
2. The crate's page would advertise the need for a maintainer. For security, the previous maintainer would still have to approve ownership transferal.

Personally, I'd like this feature so I could give away the udev crate (or at least warn its users of its deficiencies). TL;DR, I didn't realize how much work a proper udev library would be (the C libudev library does some pretty shady things). Tangent below.

---

Tangent: Once upon a time, I was a naive little programmer who thought that systems programmers wrote good, robust code. I took it upon myself to implement an interface for the udev subsystem and thought "Hey, writing this from scratch is would be hard but here's a nice C library (libudev) that does everything I need; I'll just wrap it!". After publishing an initial version, I started asking myself "hmm... Could I make a better query API? What Guarantees am I even making, really? What if file X contains a null byte?". After reading through the libudev source to answer these questions, I realized that whoever wrote that code never even considered these questions. Unfortunately, I don't really have the motivation to implement libudev from scratch correctly.

[Stebalien]

Note: This would also allow packages to be hidden from crates.io search results. I'm sure I'm not the only maintainer who would like their old libraries to be swept under the rug so to speak...

[alexcrichton]

I believe that in the past we've also had similar desires for deprecating an entire crate. That way anyone using it would get warnings along with a custom message to do something else, and it'd fit in nicely here as well.

Either that or deprecating a version of a crate with a warning message along the lines of "this is insecure" or "this will stop building in 2 months", etc.

[ibabushkin]

Is this still relevant? Sounds like a thing I'd love to work on.

[theduke]

I think this is important functionality.

I'm not so sure about an "orphan/needs maintainer" status, but a "deprecated" status would be great, where you can mark the crate as deprecated with an explanation and a deprecation warning is printed everytime cargo fetches / updates the library.

If @ibabushkin doesn't have time, I'd dive into the code a bit and give it a try.

[theduke]

Point in case:

https://github.com/dckc/rust-sqlite3 was just retired in favor of https://github.com/jgallagher/rusqlite .

@dckc asked what to do with the crate now: dckc/rust-sqlite3#46
That's a exactly the situation where this would be great.

[ibabushkin]

Oh, I've begun working on it, just stalled for unrelated reasons. I'll ping back when I have something ready to look at.

[ririsoft]

Another use case with tempdir being deprecated in favor of tempfile, maintained by @Stebalien who reported this issue. The deprecation is not active yet but I would really like cargo to tell me when I can move to tempfile.

@ibabushkin: are you still working on it ?

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

[ghost]

It'd be nice if someone reopen the issue because I'm working on a crate and I'm investigating the ways to pass it to another maintainer.

[ehuss]

I'll reopen it, but it seems like there are a few related cases where people want to convey messages to users:

• Display a notification and reason that a crate has been yanked (Bump ember-concurrency from 1.2.0 to 1.2.1 #2608).
• Display a message that a crate is no longer maintained/looking for a maintainer, or is deprecated and there is another crate that should be used instead.

There seem to be some questions that should be answered:

• Are messages free-form, or restricted to templates?
• How large can messages be?
• Where should the messages be stored? The registry or the index? If it's from the registry, the details there can be tricky.
• When/how are the messages displayed? Are there concerns about it being noisy? If it's in a nested dependency that you can't control, do you just live with the noise until the other project can be convinced to fix it? How do you make clear what actions should be taken? Which dependencies are using the affected package?
• Are there concerns about the content people will put into messages? What if they start saying, "hey, you should upgrade to the latest version, it's faster!", does it add more noise that will be annoying? Or maybe messages that are less appropriate. Should they always be in English?

[epage]

We've had a field for maintenance status but the problem is that the field is immutably associated with that version of the crate and to change the crate's overall status requires a new publish. Because of this, its fallen out of favor.

We also have cargo audit which tracks maintenance status and can error on use of unmaintained crates.

[epage]

For me, the core of this issue is a specific type of mutable metadata for crates.io (#7146) that affects rendering and could aid in handing off of crate names. All of that needs to be decided and designed before we can evaluate new lints around this.

Moving this over to crates.io to track that work