Some aspects of packagefs

8

We are spending time doing development. You have defined the thing we are working on as “non-valuable”, and thus “a drain on resources.” We (and a lot of the community) do not define it so.

However: Even if we had used pacman or something like it, wouldn’t we want a native GUI for the package manager? We wouldn’t have just picked some Qt tool, as we want it to work in the base install without Qt. So wouldn’t we be writing a GUI for managing packages, either way? So then, how is this a “drain on resources”, even if you don’t think the chosen architecture is a good one.

It has nothing to do with “principle of least astonishment” and is simply a bug; HaikuDepot does not refresh repositories on first launch in some cases. @Diver has also complained about this (and filed a ticket); I expect it will not stay broken forever :slight_smile:

1 Like
9

Your just being contrarian now.

And yes a GUI is nice… the one we have is definitely not nice. It has multiple tabs that do the same thing in different ways this is just confusing, if someone wants one or the other just split it into two applications… BeOS/Haiku is a power user OS go with the condensed list and call it a day.

I think the motivation for this was that some wanted the Native applications promoted above any other 3rd party applications, but this has lead to terrible UI design. It would have been better to have a “BeAPI” tag etc… and just promote those by default, but even that breaks the end user friendly policy of just alphabetizing the packages.

10

There’s a feature request open for a “BeAPI” tag on the HaikuDepotServer repository, actually, so that will probably be implemented at some point, too.

2 Likes
11

Btw problem had nothing to do with not refreshing repos… it was that the big icon view was default and there is no # of packages available shown anywhere and yes I think there is an unresolved bug report about this still IIRC. so… people just opened the big icon view and assumed there were only like 20 packages available and said MEH!

I know that is kind of dumb… but that is reality.

12

Yeah, and now there are tabs that clearly delineate “All packages” and “Featured packages”, which makes the difference between the two very clear.

13

All I’m saying is that it shouldn’t be there… if anything just default the query to featured etc… kind of greyed out and then when you type something in there it overrides that and does what you want with no need for tabs.

14

Regarding package manager / PackageFS “draining” development resources. You can remember when LibreOffice was ported, the current package manager was explicitly acknowledged as one of the main features that made porting even possible. The port was unsuccessfully attempted prior this stage. So package manager / PackageFS at very least regains some time and effort too.

15

None of the LibreOffice and Qt (including Otter browser and the like) would have been possible without a package manager. And Haiku would still be a toy OS with no office suite and no decent web browser. It was also highly motivating for developers because it’s one of the places where we have shown that the approach we use in Haiku, to rewrite a lot of the software components rather than reuse existing ones if we don’t like them, showed that it can work. The package manager is possible in this way because the developers doing the work could work on the command line tools, the kernel, the bootloader, the filesystems, and also the infrastructure to port packages, all at once, and build a solution where everything fits together. Installing and uninstalling packages is super fast, you can rollback to older states, installing Haiku is almost instant because there are now just a few hundred files to copy instead of several thousands.

The system is not without problems, one is the dependency hell of non-Haiku siftware but no other package manager would solve this, we knew it would happen, and we hope it is only temporary as the ecosystem of native apps grows, but in the meantime we have to provide some usable apps to our users to get things started. The other is HaikuDepot, which tries to be both a package manager and an app store, and fails at both; as well as the Repositories preferences and SoftwareUpdater, which are both not that great in terms of UI design. Both of these issues are unrelated to the package technology chosen.

Switching to something that extracts packages would make installing and uninstalling packages slower, installing Haiku would take much longer, no rollback possible. And yes, users could mess up their systems and make bug reports no one manages to reproduce because they forget they have modified some file, and their changes would get overwritten on updates whereas in the current situation, they are not, instead they are clearly separated in a non-packaged directory.

Also, this has been debated a thousand times on this forum and on the mailing lists before, and no, we’re not changing our mind on it. If you have actual problems with some specific packages, we can fix that (usually rather quickly). If you just have a general feeling that “things would be better if…”, read the original discussions that led to the current design, and come up with a scheme that checks all the requirements and brings something new, without additional performance hit, and then we may consider it.

Sorry, but it’s quite annoying to have this discussion over and over again and always rehash the same arguments.

12 Likes
16

Although just an end user in Haiku I fully agree with @PulkoMandy reply.
I am using package managers on Linux for years now and I have read portions of this debate for Haiku in the forum.
I am using HaikuDepot and SoftwareUpdater, mostly without problems. And I have used the rollback state mechanism enough times to realize its usefulness. Only once needed to run pkgman fullsync.

Specialists answers above fully covered me.

Just my 2 cents as a lifetime C++ developer, multiple OS’s user/experimenter and Haiku user-enthusiast: Haiku devs did the correct thing with package manager design/implementation and I highly respect and appreciate their work.

4 Likes
17

i think i agree with you @fkap as linux user that change many distro before… i fall in love with porteus linux and haiku… they both share some similiar aspect for software packaging…
for now i use more haiku than porteus… altough porteus seem faster and use smaller memory footprint but i’m sure that haiku will better and will surpass porteus… who knows…

1 Like
18

Note I did not say I dislike package management… I dislike packagefs and the invasive changes it makes that degrade the experience on Haiku as well as all the issues it drags in from being complex.

As far as that goes… if the issuse were actually dealt with instead of being perpetually WONTFIX… I wouldn’t care but I suspect they mostly derive from the excessive complexity in packagefs for the most part.

Mostly I think package management with the features it has now should have DEFINITELY been pushed to R2… and instead of making a read only package filesystem. Something akin to ZFS or XFS with snapshots should have been implemented for R2. That would have meant ZERO changes to where programs expect things to be… instead we got this convoluted mess that definitely no end user would ever expect to be this way.

19

What is complex in packagefs? It is basically read only compressed file system with folder merging. It is already working, only minor problems are present like post install events are not executed properly. This problems are not specific to packagefs and work in same way as package manager in Linux.

1 Like
20

It’s layers of indirection to what is actually on your computer.
shinethrough and non-packaged nonesense.
Working… I guess if you count doubling system resource usage at a minimum.
So in addition to that it also fails in the same areas typical other package managers do…-_-

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.