Support package deprecation in the Depot

[elliott-davis]

@adamleff commented on Fri Sep 15 2017

A while back, we decided to move InSpec from core/inspec to chef/inspec since it didn't make much sense to have it live as a core package, and none of the InSpec maintainers who control the release are core maintainers. However, since core/inspec still exists (because we all agree removing packages from the depot is A Bad Thing(tm)), it recently caused a problem when trying to automatically rebuild the world for the recent Ruby CVEs.

I'd like to propose a mechanism for marking a package as deprecated such that bldr doesn't try and rebuild it. Bonus points for the ability to de-list the package (while still having it available as an artifact), and double-bonus points for the ability to redirect a user from package A to package B so they can find the new hawtness.

Sorry if this is a duplicate. I know this has been chatted about before and I tried to find an existing issue unsuccessfully. Thank you!

---

@tashimi commented on Sat Sep 16 2017

Agree! This is something we need to add.

---

@lilianmoraru commented on Thu Dec 28 2017

Related issue #1051

[lilianmoraru]

I was planning to close my issue since I consider that the "stable" and "unstable" channels solve my initial issue.
You move the package to unstable but still allow those that have a direct dependency on it to download it(Even while building this works: mentioning core/glibc will pick only stable but mentioning the fully qualified path will download unstable packages if necessary).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.