11:57:40 let me ask this question even if I likely just have the answer (because I didn't find anything about this in the man pages): is it possible to have 'pkg update' stop just after the download phase? 12:00:28 I'm asking this because the download part is the often the longest one and I'd like to reduce as much as possible downtimes, since the workflow is often this one: 1) stop production services; 2) let 'pkg update' create e new BE, then update and activate that one; 3) reboot the host 12:03:08 since the new BE creation step is just after the download process... I'd like to pre-download new packages and, only after that, to stop and update the host, just in order to reuse the downtime phase (this is what I usually do in FreeBSD, which is why I'm asking) 12:03:44 s/reuse/reduce/ 13:44:59 There isn't a way I know of to split up the download and other stages like that, but you can set up a local mirror of the repository or download all of it into a local archive file, and then update from that. 13:45:27 It may not be too hard to extend pkg to support something like that though. It's a nice idea. 14:35:09 @andyf: thank you! I’ve zero knowledge to contribute to such a change (only fully available for becoming a beta tester of this feature), but I’ll study for setup the local mirror. 14:36:02 I think there might even be a service that does it, but it's been a while. I can help with either option if you get stuck. 14:36:12 I'll plan to see how it could be done in `pkg` too as it sounds like a useful feature. 15:08:13 I found this post about IPS mirror: https://antranigv.am/posts/2024/02/omnios-mirror-one/ and I’ll give it a try ASAP 15:10:09 However, I think it would be wonderful if such a feature will be added to pkg… let me know if and how I can be of any help on this (since I’m a sysadm and not a dev) 15:12:55 warden oh that's my blog post! 15:13:50 warden I forgot to publish parts two and three. oops 15:20:52 antranigv: well, at least it’s a point I can start from… thanks! ;) 15:28:53 antranigv: duh, dobit immediately. You have promised more articles, remember?! 15:29:46 *do it 15:49:59 Thank you andyf & friends for pulling fenix illumos 17766 into '054 and later. 15:50:00 BUG 17766: xsave area sizing must only consider enabled components (Closed) 15:50:00 ↳ https://www.illumos.org/issues/17766 | https://code.illumos.org/c/illumos-gate/+/4477 15:50:00 BUG 54: metaslab_min_alloc_size may be too big (Closed) 15:50:00 ↳ https://www.illumos.org/issues/054 15:52:44 It will be in the next release, which we're preparing now. 16:06:07 Again, thank you! (Will update HDC's 156 at that time.) 18:08:13 warden: I second the recommendation on maintaining a local pkg mirror. 18:09:06 New weekly releases have just been published - https://omnios.org/rn/r56 18:11:15 sommerfeld: yes, even if in case you are managing a single bare-metal or VPS hosted in someone else' datacenter, it would be preferable to have a sort of "--download-only" option for pkg(1) 21:59:29 s/even if/but/ 22:24:32 seeing the bits earlier about downloading packages separately from the install phase, another use for that sort of functionality is if you have pre-prod and production setups. You can then do the package download at the same time on both sets of systems but stagger when they're installed. 22:26:09 it's a bit of a hacky way to do the release management bits, but gives a fairly good chance of installing the same set of updates on both sets of systems (rather than potentially getting newer sets of packages in production if the download is that the same time as install) 22:46:49 Yep, if the download-only function isn’t too cumbersome to add, it would be a valuable improvement for a lot of people. All others pkg managers I worked with (FreeBSD’s pkgng, NetBSD’s pkgsrc) have it and I always made good use of it! :)