In D50331#1157176, @dch wrote:

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

Address some of the issues mentioned here.

I like this article. A lot. No specific feedback, just a general comment - who is the target audience for this?

I see, so we are not planning to disable them at this time. Sorry for the noise.

LGTM

It would be very good to get this committed (to main) before this week's snapshots

In D47942#1094368, @bofh wrote:

In D47942#1094365, @bz wrote:

@bofh are you going to commit this?

To be frank, although I wear a re@ hat, we have strict directives from @cperciva not to commit to /release without his approval. As he is in AWS REINVENT for now; I am not sure how this works. :(

In D47942#1094365, @bz wrote:

@bofh are you going to commit this?

@bofh are you going to commit this?

I am still contemplating if we should simply put the cache-dir outside the

In D47942#1093222, @emaste wrote:

want to remove the repo data in the cache and unregister the pkg itself like what we do in VM

Perhaps, but I think this issue is fundamentally different than the VM case and I would suggest we both make this (D47942) change and MFC it as soon as we can, and consider following up with further changes.

want to remove the repo data in the cache and unregister the pkg itself like what we do in VM

In D47942#1093167, @lwhsu wrote:

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

That's a good catch, and not sure if we also want to remove the repo data in the cache and unregister the pkg itself like what we do in VM. Having those might cause an issue when pkg is boostraped but repo data is seriously out-of-date. We encountered this in the past in the cloud images.

Thanks Mitchell!

Thanks! That seems much more reasonable than what I was thinking.

I'd drop all the changes before 12.x. The CS driver was around for a long time. I forget which release we dropped it in, but changing things older than 12 is likely not a good idea.

Missed a spot, sorry.

Yes. I also wondered if the website could have the template build as "CURRENT" continuous release notes so we'd have an almost constant view of the expansion and the state of FreeBSD main AS-IS.

In D47272#1084351, @mhorne wrote: