On Fri, Jan 12, 2024 at 08:21:17AM -0600, Matthew R. Trower wrote: > > On 1/12/24 04:41, Marcel Telka wrote: > > On Fri, Jan 12, 2024 at 04:08:12AM -0600, Matthew R. Trower wrote: > > > /var/pkg/publisher is exactly what I thought it was. I am still not > > > clear as to whether the format is committed(stable) across different > > > versions of pkg5, and therefore safe to share across BEs. > > > > The man page says: Interface Stability: Uncommitted > > My understanding of the Interface Stability attribute is that it applies > to application programming interfaces (source and binary). I would not > expect it to necessarily apply to the data storage/caching layer of a > program, as I would not expect that to be considered an application
Your expectation is wrong. Almost everything constitutes an interface. See also attributes(7). > interface layer. Furthermore, the Interface Stability attribute was > conceived back at Sun, and applied to their specific release strategy. > OI has diverged significantly from Sun's release schedules, > methodologies and motivations, so you'll have to forgive me if I don't > take the attribute as gospel these days. Sure, np. In that case you should consider everything as Volatile :-). See attributes(7). > I'm really just asking: how likely, these days, is /var/pkg/publisher to > change in breaking ways? I know from observation that it has changed at These days? Unlikely, because of the activity in the source repo at https://github.com/OpenIndiana/pkg5/commits/oi/ . > least once since OpenSolaris, but that could mean once ever, once a > year, once a month... it could be changing twice a week for all I really > know (okay, that's an exaggeration, but hopefully you get my point). > The people who actually do the bulk of the work on pkg5, are in a better > position to know this than I ever will be through trying to scour man > pages and source diffs. RTFM is fine and all, but sometimes it just > doesn't cut the mustard. > > Ultimately it's not that big of a deal, I guess. I was just hoping to > save some disk space instead of dragging around every package I've > downloaded since the beginning of time. But I've got new disks coming > in now anyway, so... meh. That really depeneds on your usage scenario. I run some systems almost always up-to-date with non-illumos-gate updates at least once a day and full updates (with reboot) every few days and here is an example: # du -sh /var/pkg/publisher/ 1.17G /var/pkg/publisher # and I do nothing special to keep it that way. This particular machine have almost all available packages installed. > > and no (because if such files have no relation to IPS then they > > won't appear there; but maybe you thinks about different kind of > > "relation" :-)) > > No relation as in "not under management". I doubt very much that pkg is > having those other kinds of relations :-) > > If I install my own /usr/bin/zsh, then later install pkg://shell/zsh > through pkg, pkg will take my old /usr/bin/zsh and chuck it in the > lost+found --- because that existing file has no relation to IPS (it was > not under its management). That is my interpretation of the man page, > anyway. Seems sensible. Yes. Sounds reasonable. > > I think yes (for example when you uninstall a package) > > If uninstalling a package places files in lost+found, then I'm well and > truly confused. To confuse you a bit more here is an example: # find /var/pkg/lost+found/ -type f # echo test > /usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info/TEST # pkg uninstall pytest-randomly-39 pytest-randomly ... # find /var/pkg/lost+found/ -type f /var/pkg/lost+found/usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info-20240112T154031Z/TEST # cat /var/pkg/lost+found/usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info-20240112T154031Z/TEST test # -- +-------------------------------------------+ | Marcel Telka e-mail: mar...@telka.sk | | homepage: http://telka.sk/ | +-------------------------------------------+ _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
