Some aspects of packagefs

21

Package management is complex. Something like apt on Debian requires maintaining a complex database of packages, breaks apart whenever you modify a config file with a “oh no you CHANGED A CONFIG FILE! THIS IS NOT ALLOWED and I’m not updating it now, go figure it out yourself”. It also has no rollback feature, it does not allow getting the packages from an existing running system, etc.

Again, please read the checklist we had all agreed on and that led to the current package system design. No Linux package manager fulfilled it. That was the first thing we tried, of course, because it would have saved a lot of time. But we found nothing suitable, and only after checking that we went on with creating our own.

And no, it’s not that complex. It’s essentially just a filesystem. There was also indeed zero changes to where programs expect things to be: libs in /boot/system/lib, config files in /boot/home/config/settings, as it has always been on Haiku.

I’m trying to look for the “wontfix” issues you mention. Well, we don’t even have a “wontfix” category on the bugtracker so I tried an approximation:

https://dev.haiku-os.org/query?component=^File+Systems%2Fpackagefs&resolution=invalid&resolution=no+change+required&resolution=junk&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

First ticket: closed as invalid by the user who reported it.
Second ticket: was a problem that should have been reported on haikuports (and it was fixed in the relevant package)
Third ticket: trying to make a package that puts things in the non-packaged directory. I think we can all see why this would be a bad idea? The problem was still solved by changing how the package in question creates its deskbar entries (which certainly doesn’t require writing into non-packaged)
Fourth ticket: turned out to be a filesystem corruption on an USB stick completely unrelated to packagefs.

… and that’s it. The complete list of “wontfix” tickets.

Now if you have actual problems with packagefs, please open tickets and we’ll see what can be done. If you have only whinning and complaining about “it’s complex”, I’m not sure what we can do, however. We could remove shine-through directory and non-packaged to make things simpler, but it seems obvious that this would remove important features from the OS, like, I don’t know, the ability to save settings? And if your plan is “remove packagefs”, again, you have to come up with an alternate solution that performs as well (or better) in terms of features and performance.

About the memory usage now: there is indeed an OPEN ticket about it, and you know about it because you complained there already: https://dev.haiku-os.org/ticket/14831 You can see that there was already one thing fixed (adding O_NOCACHE) and that the ticket is still open because we do plan to get back to this problem. It’s just rather low priority because even at 300MB, we’re still using 10x less memory than any other OS out there for a full system with desktop, and our main target is not 15 year old machines with so few memory at the moment.

3 Likes
22

I appreciate a lot the way that @waddlesplash, @PulkoMandy and others reply in this forum by presenting facts and completed logical thoughts. In an era that anyone can claim anything it’s very important to talk with facts and be pragmatists. Otherwise, development (not even OS development), which is already a very advanced/complex human process can become uncontrollable, leading to no end-user results and dead ends. All that even more so when a lot of people need to cooperate remotely to build far from trivial stuff. Need to communicate in a precise, concrete (not-abstracted) way in order to communicate effectively and productively.

1 Like
23

Frankly I dont appreciate what you are implying… you seem to think that the things I stated were not facts.

Haiku used to use under half the ram it currently does, that is a fact.
A conventional package management system would not contribute to ram useage, that is a fact.
Filesystem snapshotting can be implemented without contributing significantly to ram usage that is fairly likely but I don’t know of an implementation.
It is a fact that Haiku’s package management currently is not ideal… and even interferes with running stock BeOS software, that is a fact.

Never in this topic or any other have I ever said package management is bad… what I have said is packagefs is bad, packagefs itself has nothing to do with all the advances made with HaikuPorter which frankly doesn’t even require package management at all… though it is a major convenience to have it in conjunction.

Many of the ways in which package management on Haiku works were implemented against what many people who enjoyed using Haiku and BeOS wanted… mainly in the areas of comparability and how the filesystem layout has been hacked up.

24

As PulkoMandy has pointed out, a conventional package management system offloads complexity to the user.
I’d rather prefer if that complexity was handled by the software. RAM is cheaper than brain cycles.

Complexity has to live somewhere. You can’t just remove it.

1 Like
25

I will try to explain myself a little better.

What you repeat to me as facts/arguments have already been commented/answered very detailed, one by one, from @PulkoMandy and others that are aware about the related code and its design. Based on these replies (related tickets on packagefs e.t.c) I understood that not all of what you stated are facts.

I, as just a final user and not haiku developer, I had no problem so far with the package file-system being read-only or with its memory consumption. My opinion is that any discussion related to lower Haiku’s memory consumption should be of extremely low priority (as irrelevant in the real world we live in and the reality of operating systems) compared to other critical things like fixing the issues of Web+ which is number one blocker for many people for everyday usage. To make it more clear, any memory discussion to make the system run in 128Mb is very nice for academic/experimenting reasons but it gives no real value to end users. Zero. And we need these end users.

Again, my personal impression is, and of course I could be wrong, that you don’t like/agree with packagefs (or general Haiku’s package management?) design/implementation and maybe you would do it in another way. That’s totally acceptable but it has nothing to do with specifications and actual bugs on how the related software works. It’s just a matter of personal preference. But as an end user/observer I really don’t see how declaring repeatedly your personal preference/dislike helps to make progress on the specific subject.

It’s nothing personal since I don’t really know you (!), just my opinion and impression based on what I have read here and my usage of the system. I had no intention to insult you and I apologize if I did.

3 Likes
26

I really like Haiku’s package FS. The other day an update to QtCreator broke parsing the cmake project settings. Until I identified that the issue was with legacy QTProject settings file causing QtCreator to break (and with help from 3deyes - Gerasim), I had to switch between older and newer versions of QtCreator and cmake. The administrative cached older packages saved me tons of time and made the whole investigation extremelly easy. I was able to reinstall versions as quickly as it took to mount and unmount an image.

Bliss compared to the non packageFS way in most Linux distros. Haiku PackageFS is a generation better than most things out there.

2 Likes
27

You can do the exact same things with conventional package management in fact this is exactly what ArchLinux users do… when something goes afoul… granted being Linux it isn’t done elegantly.

Also you can’t say you’d rather have software take care of the complexity… while at the same time making things far more complex than they were before. packagefs DOES NOT… follow KISS principles or the principle of least astonishment AT ALL not even remotely.

28

This is partially true yes… packagefs itself is inefficient and so far no one has been able to fix it and I frankly doubt that even if all the cache issues are gone that it will not have serious overhead. It also makes the Haiku file hierarchy unfriendly and complex.

I have no problems with package management or HaikuPorter… at large, frankly I though the the original detractors against packge mangement at all were crazy.

29

Keeping installed files database and maintaining consistency is more complex and error prone then mounting packages as file system.

As you see in this topic, most users are fine with packagefs, if you want something different you need to implement and maintain it yourself.

4 Likes
30

If you don’t have anything constructive to add maybe you can go start your own thread on some other topic rather than commenting here… also most of the people making any substantial comment one way or the other just made a bunch of non answers to my complaints, to distract from the issues at hand.

Basically saying Package Management is good, why do you hate it… and I’m like -_- you clearly didn’t bother to read my post.

That’s the kind of logic you are using against me.

That is rubbish… no other system with package management has roadblock issues and there are very obvious long standing solutions and mounting packages doesn’t fix anything at all in that regard by comparison it just closes its eyes and says they don’t happen. config files are still an issue and are acutally a source of added complexity with how packagefs works…

31

If package is installed by unpacking, its contents can be changed by various reasons and can lead to cryptic errors. packagefs do not allow this by design. Storing archived packages (/var/cache/apt/archives/ etc.) is required to repair installation that lead to disk space waste. Config files are unrelated to packaging, it work in same way as BeOS.

3 Likes
32

I’m sorry but that’s again completely wrong. BeOS applications install in /boot/apps. Not /boot/system/apps but /boot/apps. /boot/system didn’t even exist in BeOS, it was called /boot/beos and you were not supposed to touch anything these as this was the system folder just like in MacOS.

/boot/apps is still perfectly writable and usable to install your BeOS apps.

I have offered, and this still stands, that I will investigate and fix any problem with BeOS apps. As far as I know, none of the problems reported have been caused by packagefs. I fixed issues in the LegacyPackageInstaller, I fixed the size of the preview in the ScreenSaver preferences to avoid some screensavers crashing because we asked them to render a preview at just the wrong size, I fixed issues in the game kit. Never one of the bug ended up being because of packagefs. So, please, facts: can you find even just one BeOS app that is broken because of packagefs?

4 Likes
33

If your concerns are only with packagefs, maybe you should use Hakilo. Help S40in to improve it, to promote it. Whatever the way, it would be certainly more productive. Or do your own distrib. If your vision is right, no doubt that your community will grow faster than Haiku one and you will have your point.
Understand me, I don’t want to be impolite. I only state that debating of this over and over won’t make positions change and Haiku will still use packagefs.
Also, time spent answering on forum is certainly for devs a way to relax and to take a break from coding, but honestly answering same questions again and again must be not only tiring but also demotivating.
After that kind of endless discusion, I wouldn’t feel like going back to bugs fixing.

1 Like
34

Just commenting on the ZFS part here since it got lost in the conversation and copy on write with all its use cases is a really great feature of modern file systems – this would surely be a great feature for BFS 2 but that’s after R1…
Having said that and using it since it got integrated better into Linux land, I’m still missing time machine like functionality for end users, so it’s also not that useful for Linux users on the end. That could be implemented vastly better in HaikuOS I believe.

35

Oh come off it… you know every well there has been an endless stream of BeOS apps that don’t work after packagefs was implemented for YEARS… it made something that should not have been ever an issue a huge problem for anyone picking up Haiku and installing an old Be app.

The fact is during packagefs development a lot of people just up and left Haiku because of all the breakages that were caused… and the only reason many apps work at all these days is source was available and they were repacked.

36

I have no interest in a fork, every single one of them has eventually failed.

What I do have interest in is not getting complacent with bad problems with packagefs.

37

List please.

2 Likes
38

How about you spend a bout 5 minutes searching this forum, the mailing list and ticket tracker… I’m not going to do it for you. There was A MASSIVE amount of backlash over packagefs at the time and frankly all the main issues are still there.

Most users DO want package management… but and that is a big but, no users should be wanting package management that makes what was once a simple operating system complex. That means instead of read only by default it should have been read write in most areas by default just as EVERY other operating system. At the very least in entirety of the user folder…

It doesn’t matter what nice features you gain if you trample quite a few others along the way.

39

I’ve spent quite a lot more than 5 minutes on the bugtracker, and I can tell you that most “compatibility issues” were bugs reported against LegacyPackageInstaller, and have since been fixed. So, do you know of any applications that still do not work after this?

There was a large backlash, yes. But things got better, and most of the users came around, and a few even “recanted” some of their more polemic statements from before. And again, we really did not expect Haikuware to just up and disappear entirely…

40

Why don’t you list the apps you claim don’t work? Why should other people do it for you?