Some aspects of packagefs

1

Some aspects of packagefs are equally unpopular so… yeah. Having used packagefs Haiku somewhat I’m of the opinion that it causes as many problems as it fixes, which is pretty bad. Would I switch to a plain old tarball style package manager like pacman… you bet I would in a heartbeat. The things packagefs was supposed to solve it doesn’t even solve in practice, with a lot of packages in the repo just being broken on nightlies because nobody knows a package is broken untill someone tries to run it currently… maybe that’s more the fault of the package builder infrastructure dunno.

Over doubling ram requirements, being really slow in HaikuDepot, and generally not being any superior in practice to regular package managers… while drastically changing some aspects of file system layout. Being an overcomplicated massive development time sink also (it sucked away several years all by itself and continues to drain). Hmm… you be the judge. It also makes development and testing of core systems more complex… just try to explain testing a driver to someone not familiar with Haiku… the old way was very very straightforward.

2 Likes
2

Cb88, I disagree with your opinions re: the PackageFS. There are benefits which outweigh the complexity:

  • booting into previous state (#1 benefit)
  • read only system
  • easy package removal
  • faster install/mount
  • etc

The problems people are complaing about are due to lack of developer attention (primarily man power and other bigger issues to resolve). There are optimisation opportunities for anyone with time - the install image can be made less memory intensive if anyone willing to experiment / work on it, but sincerely I doubt any of the core devs would spend their precious time trying to resolve booting on 256Mb systems. There are more beneficial problems to resolve.

Here is a suggestion which is almost trivial to do for any skillset person. Start with a default nightly, uninstall what you think is not needed, reboot(test), rinse and repeat. Eventually you’ll end up with what may be a minimum low memory Haiku install image. It would be interesting to see how low you can go. The effort is roughly one evenings worth of work. Almost anyone can do it, probably even a pre-teen.

Personally, I think the install image is too small. I’d bundle a lot more …

2 Likes
3

Literally have no use for that, and if I did, I’d want it to be like ZFS and not a hack that only works for packages themselves.
Again… no use for that, as it is a hindrance as I’ve already mentioned.
Again… every Linux distro does this.
Faster install mount… except you have to do this at every boot rather than be a one and done install.
etc… nobody has convicnced me yet that this was the right path.

Sometimes the right answer is to follow KISS philosophy and stop making things complex for no real common use case benefit.

4

Nope. There is actually a report that says exactly what is broken. E.g. https://eu.hpkg.haiku-os.org/haikuports/master/x86_64/current/repo_consistency.txt

Sometimes people do not get around to fixing these, but hey, it’s there.

This is entirely a problem with HaikuDepot (and a number of changes to HaikuDepot have been merged in the last few days that greatly improve this situation.) Running pkgman search, for example, shows how fast the package manager is underneath truly.

It took a lot of time to develop, sure. But that it “continues to drain”? Where do you see this?

In the “old way”, if you tested a driver that broke your system, you had to boot into a separate install to remove/replace it. In the new way, you just set “Disable user add-ons” in the bootloader, and you are done.

In the “new way” (with the exception of “boot” drivers like USB, SCSI, etc.), you just send someone the driver and tell them where to put it in non-packaged, like before. Or you can send them a single package (if made properly, it needs a “system” flag) and it will also work. Or you can send someone an entire “haiku.hpkg” (works even for “boot” drivers.)

Is the new way trickier for developers? Sometimes. But personally I prefer being able to recover my system without fiddling around for a pen drive or something.

Some other upsides Zenja did not mention, that I also like:

  • Being able to change/add/remove what packages are installed, without having the system running.
  • No “installed files database” to get corrupted (as every other package manager does, and yes, this can happen…)
  • Packages are stored compressed, and take up less space on disk, while the rest of the filesystem is uncompressed.

I don’t really know how you can say that booting into a previous state has “no use” for you. How much do you run Haiku nightly builds? It is an invaluable feature there, as any tester or user of them will tell you. (Sometimes it is useful even when just taking software updates, too.)

You continue to claim that “no real common use case benefit” has come from these complexities, but plenty of users (and developers – and let’s not forget we developers are also users!) disagree.

5 Likes
5

It’s very easy to get rose colored glasses about something you had a part in… I’m pointing out my experience is that the packagefs is nothing but a pain in the rear for me.

The fact that the Haiku and CLI app don’t work equally well is not a pro… from what I remember they dont’ share much code either which is another knock.

The boot from previous state is like ArchLinux users saying that not automatically purging old packages from cache is a nice feature that can save your butt rather than shipping something stable… yes it’s all true but it doesn’t help the end users experience be good.

I have several PCs I come back a month or two later and try to update… put in the correct repo urls if anything changed… and nope it still doesn’t upgraded properly.

6

I didn’t have a part in it, remember? I showed up in the community shortly after R1/alpha4, and only barely started contributing patches by mid-2013. I was completely uninvolved with the design and implementation of the package manager; I didn’t even get involved in HaikuPorts at all until 2014, after the package manager had been in place for quite a while.

Of course it’s not a pro; like I said, it’s being worked on.

The CLI application just searches, installs, etc. packages. HaikuDepot is a full-featured GUI. They share the underlying Package Kit code (transactions, package_daemon/packagefs interface, etc.) but of course their “UI” structures are different, since one is a CLI and one is a GUI.

Then that would be a bug (if you were using SoftwareUpdater, there was indeed such a “bug” where it always ran “updates” instead of “full-syncs”, this has now been fixed.) If a pkgman full-sync does not fix this problem, file a bug (but I imagine it will.)

1 Like
7

Like I said a drain on resources. I mean this has been one of the things I’ve pointed out from the beginning is that HaikuDepot tries to gnomeify the package management process and dumb it down… and frankly that’s just wrongheaded. I mean we had reviewers on youtube saying that Haiku only had a couple packages available when in reality there were thousands in the repo because the UI does not follow the principle of least astonishment.

Yeah I haven’t tried from pkgman… that might do it.

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…-_-