Works for my use case. If a user wants newer packages they update.
I'm an old oil industry guy. Got tired of fixing the same problems. State of
system audit is a big deal. I want to be enable to exactly inventory and
replicate a system as I did when it was a 3/60 or 1+.
I even implemented per user control of version executed so I could debug the
same program while another user tested a different bug fix. I also used it to
test betas on the noisy users before rolling it to the masses.
But it meets the replication constraint. Whatever the state of the machine
was, it can be reproduced.
On Saturday, November 22, 2025 at 10:36:01 AM CST, Till Wegmüller
<[email protected]> wrote:
The Update frequency is definetly for Python packages a lot higher, so
we will need to find ways to handle those. By just removing the
Colsoidations from the Server side the client would keep it at the time
of the last update and grab all the packages from that time when you
just install. It would not allow you to fetch new versions packages that
exist now but not during the time of the last update the client made.
-Till
On 11/22/25 16:02, Reginald Beardsley via openindiana-discuss wrote:
> The semantics I am requesting are as follows:
>
> When a release is made, a snapshot of the repository is taken and an
> identifier assigned, e.g. the name and date of the release
> Keep the updates mounted. There are not that many each year. If I have 25.1
> installed I want the "pkg install <foo>" to draw from the correct repository.
>
> Simply chroot(2) to the correct snapshot or similar All the rest is as
> normal.
> This will allow the user to choose when major updates take place rather
> than forcing them at inconvenient times. It will also give OmniOS
> class replication.
> The bug you don't tickle is better than the fix which breaks a critical piece
> you are running.
>
> Have Fun!
> Reg
>
> _______________________________________________
> openindiana-discuss mailing list
> [email protected]
> https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
