HaikuDepot dependencies

[leavengood]

I have been wanting to fix this for a while but have not had the opportunity yet. The general idea for cleanup of old states was to delete them to some set time frame but ensure a certain number of states remain. So, for example, keep the last 10 states, up to 30 days old. There will have to be some testing to find the best default and ensure this idea works correctly.

The reason to look at both time and number of states is to handle weird outliers like if there were no updates or installs for the last 30 days the cleanup could leave no old states if only the time frame was considered. And if you only looked at number of states, a very busy day updating and installing packages could mean you can only go back one day if the time frame was ignored.

By looking at both time frame and number of states the benefits of rollback can be preserved no matter the kind of install pattern used.

We will try to find a good default but may still expose configuration values for this somewhere.

[Begasus]

Main issue “here” is that when I build a package(s) locally and then (after buildbot finished the build) try to run “pkgman full-sync” and it’s telling me that it can’t finish (package is in use), it would be nice if pkgman would tell which package is conflicting with the update so one can remove the package (installed) so pkgman could finish the update

[humdinger]

@leavengood

I have been wanting to fix this for a while but have not had the opportunity yet.

Should opportunity come knocking, please also see if can implement a way to revert to a state. That is, if I have to boot into an older state, I’d like to be able to revert to that state permanently without having to do that manually from the boot options every time.
I suppose that would be done by removing all states newer than the currently running?

[roiredxsoto]

Good day,

As of lately I can’t listen to anything while driving, I got plenty of time to think, and mostly is Haiku stuff . Regarding the “states”, IMHO I think Haiku needs an improved method to rollback to a “stable” state, and a way to keep certain “states” saved.

Here I was thinking on how to have a tool to do it, though was a wrong approach. Actual Haiku states are text files stored in the /Administrative folder inside /home/config/packages/Administrative IIRC, and they list the installed pieces and their versions. Easy to remove by hand, or with a GUI tool. The replies I got at that post would apply to the GUI, I presume. I didn’t dig any further because lack of knowledge on Haiku

These days, I was thinking about having the Core OS isolated from the apps, and saving snapshots of “working-stable” Core OS installs. Not sure but I presume this would break the Haikuports stuff, I mean, softwared installed from Haikuports that would depend on certain OS libs. Packaging software with its dependencies could solve this, is this correct?

By isolated I mean that Haiku, the OS could install itself, and update itself independently from apps, and viceversa. As HD’s are becoming bigger (capacity) and cheaper, it could be possible to keep full OS (core) snapshots without taking much space on the disk. Besides, Haiku itself does not take lots of space, as other OSes do. With a GUI tool, user could lock an HREV and keep it on disk to rollback to a fresh state, or whatever.

I’m starting to learn more about the HPKG format, and recently read here in the forum about the disk image stuff. Also, I’m toying around with HPKGs, to see if I can get more familiar with it and get a better undersanding on how it works. I have the feeling that HPKGs are more powerful than expected in many ways.

Some might thing about AppImages, Snaps or Flatpaks for software deployment, and mostly that is the idea. I would need, once Godot is stable on Haiku, to keep several versions of Godot in order to be able to update old Games with the right version of Godot, using the one the game was developed with to reduce developing time and possible flaws. Importing a project from an old version into a new one has been a big mess for me with Unity, and with Godot moving to v.4 it will be even worse I presume, so I rather keep the version of the software the game was developed with. Also applied to Blender, from 2.79 to 2.90, opening files from 2.79 in 2.90 well… Might be my bad though. This could apply to other software too.

All this is wishful thinking at the moment, though I presume it can be doable in the near future in order to get a “safer” more stable OS. Nonetheless, R1 is the short-term goal, and there are plenty of milestones to reach before release, and this is my specific use case.

Regards,
RR

[PulkoMandy]

Putting the dependencies inside each package is something we don’t want to do, for the simple reason that it makes deploying bugfixes and security fixes a nightmare (you have to manually rebuild all these packages, when rebuilding just a dependency would work).

For things where versions are incompatible, we usually provide various versions already. This is the case for libpng, libboost, openssl, python, and we can do it for Godot if it’s needed. It’s just a matter of changing the name of the package (for example we have python37 and python38 packages and they can live side by side just fine).

The core vs apps thing is already possible: install your apps in /home/config/packages instead of /system/packages. That’s all. HaikuDepot and pkgman do not easily allow it, yet, but that can be added. And we could extend it to make it easy to create multiple directories like that, in a way similar to Python virtualenv, if desired.

No need for ugly things like AppImage/Snap/Flatpack which only results in lots of duplicated data to achieve this. The ideas and problems were already considered when designing the package system and it can do all that (and more) just fine. We’re just missing some tools to make it a bit easier to work this way, as we covered the basic needs first (that is: being able to update the system from one beta to another) and only planned for all the extra tings.

Now that haikuports is getting bigger and bigger, and there are a lot of apps, the need for all these extra features maybe becomes a little more visible.

[roiredxsoto]

@PulkoMandy

. It’s just a matter of changing the name of the package

You just gave me the answer to a test I was going to carry along this weekend. Thanks!

@PulkoMandy

The core vs apps thing is already possible: install your apps in /home/config/packages instead of /system/packages. That’s all. HaikuDepot and pkgman do not easily allow it, yet, but that can be added. And we could extend it to make it easy to create multiple directories like that, in a way similar to Python virtualenv, if desired.

This is also very good to know. That is part of another test I was planning to carry on this weekend too. Guess I need a better insight on how Haiku does things to get the most out of it, never too late to learn.
And, now that I re-read that paragraph, it’s clear that I didn’t pay much attention at HaikuDepot packages, precisely Python. True. I should have (or should have had have or had?) realized about that long ago… mmmm… aging

I had the right feeling, nonetheless…

Thanks for the explanation. Hope I won’t forget that in the near future.

Regards,
RR