Some aspects of packagefs

That is completely untrue… it worked before packagfs perfectly fine… and stop working after as folders it needed write acess to became read only so paths in the program had to change. It has nothing to do with the space in the pkg. As far as that goes HaikuPorter could do oneshot package installs the same as pkgsrc on NetBSD, you just can’t uninstall afterwards, so no packagefs is not the enabler, its just a complex system added on to allow upgrades an uninstallation, as well as many other kitchen sink features that are completely unneeded. I suggest if you comment firther to tackle the the questions at hand rather than continually dodging them by say how great packagefs is… when the fact is that this thread would not exist if it were ideal.

packagefs != Package Management… so most of the things you have said are completely off the wall… packagesfs did not enable libreoffice HaikuPorter did. The same goes for the rest of the entirety of your comment. HaikuPorter would work exactly as well with regular packages as it does with packagefs.

This thread is created by you and nobody else post reply against packagefs.

HaikuPorter depends on packagefs for building packages. It use mounted packages listed in build dependencies.

2 Likes

I downloaded it and found this to be not true, yet you continue to claim it. Do you have any proof at all, or are you just going to continue claiming it?

1 Like

I used it… it worked, download a version of Haiku from before the packagfs implementation and guess what I bet it works. And it is entirely possible there were multiple things that broke it but your space in the package was not the main issue.

That would likely be because everyone else that was having this debate LEFT… years ago. And the current developers just want to gloss over the fact that they ignored the community.

Rather than having an actual discussion, the developers that have commented here have done nothing but evade the problems. Nobody mentions that the normal writable config file areas from BeOS are not write only and you have to put things in non-packaged (insanity).

The fact also remains that when nobody complains… NOTHING, gets done to fix things, and what do you see as the latest commit on the front page right now. I’m not even saying that I’m in the right 100%… but there is a massive amount of value in debate over how things are, and we should never ever come to the point where we are complacent with an implementation DURING BETA.

Please post link to that debate.

/boot/home/config is still available is same way as in BeOS, some config files are even compatible with BeOS ones. There are no need to store config in package data.

1 Like

I already told you google it yourself… its on the ML and was on this forum before it was upgraded to discus so who knows maybe it got lost. We lost an entire supporting website over this mess ( I won’t mention him because frankly he also was a massive jerk about it).

So, you did not actually test it, then?

If you can post a link to a version of the package that works under a pre-PM Haiku but does not work under a post-PM Haiku, then we will indeed investigate. But you have as of yet failed to do that.

At least bbjimmy, who was on “your side” of the argument originally, has since come around (or at the very least, he is still around, and has not left.) So this is an exaggeration at best.

Such as? As PulkoMandy mentioned, /boot/beos is still R/W! So what else are you referring to?

Karl and Haikuware leaving was completely unexpected on our part, and still to this day makes no sense to me. Most of the software there from BeOS, or in .pkg files, still worked; and we expected they would create a package repository and start populating it with software. Instead they just up and left, and refused even our efforts to archive the site, sending us vague legal threats in e-mails if we attempted to do so.

I actually ran it for years… what’s your deal?

Also this obviously the links and things are there now, but may of the problems endemic to packagefs are there:

Note: if you want to never have this conversation then we need to resolve the problems instead of ignoring them, and going lalaalala, I wont’ allow this on the ticket tracker etc. Because 5 years down the road, someone is going to go I thought this was a BeOS compatible OS why don’t these things work and start it all over again, because Haiku has strayed from it’s beginnings for virtually no reason at all.

The complexities introduced by pacakgefs in it’s current implementation are completely unacceptable.

I’m still waiting for your actual examples of broken apps so I can investigate and fix the problems. You have found one app and we have investigated it and found that the problem was not related to package management. I’m not sure what else I can do.

I don’t think we ignored the community in designing the packagefs. You can find the mailing list archives where this was discussed at length, with everyone suggesting many ideas. Of course not all ideas could be used, there was a lot of discussion and compromises.

As for haikuporter, yes, it predates the package system. And no, it was not usable before, dependencies were not managed, it would automatically install stuff in your system without asking you so if you had a bug in your recipe, it could easily result in unbootable system. I’m certainly not going back. The read-only system folder is not a bug but a feature. Now it is reasonable for me to keep using the same Haike install for years, instead of reinstalling every other month because I attempted to install something and it made a mess in there in a way that can’t be undone.

And regarding the “everyone has left” argument, let’s look at facts. Out of our top 10 contributors, everyone was at least contributing until 2016: Repostat: git repository statistics. the one who stopped contributing in 2016 is Ingo Weinhold, guess who, the person who designed and implemented packagefs. And his reasons for leaving are largely unrelated to any of this. You can also check that the number of authors per year did not significantly go down. And on the haikuports side: Repostat: git repository statistics. the number of contributors went way up from 11 in 2012 (the last year before package management work started), to 35 in 2013 (right after it was put in place), to 59 in 2019. So, we have 5 time more people working on things now. I don’t think that is an “everyone has left” situation. On the contrary it shows how the package system helped attract new contributors to Haiku and make it a quite active project.

You have also been unable to list any name in your “everyone has left” argument just as much as you have failed to list any problematic software in your “all software was broken” argument. So there is nothing I can do to help here.

2 Likes

We DO want broken apps to be reported on the bugtracker. We’re waiting for that. Please test as much apps as you can and report the problems.

2 Likes

It isn’t the APPs that are broken… so why continue repeating that nonsense. The death of BeOS applications by a thousand bug reports is frankly terrible.

I’m not asking you to do the impossible I’m asking.
The BeOS read/writablity of the filesystem be retained as it is central to usability. If BeFS is nt’ fast enough to do this we shouldn’t be hacking around with a complex read only files system structure but should be jotting down plans for BeFS2 etc… or whatever. As it is now Haiku completely breaks the filesystem and UI “contracts” that have been made with the end user for since the creation of BeOS.

non-packaged be changed to packaged… any new applications can be expected to update to the new location for placing new config files and be linted to inspect that they are doing so. Old packages can continue as normal.

This makes things very obvious in how they work rather than convoluted and non obvious as they are now.

One of related discussions: https://web.archive.org/web/20140209021431/http://haikuware.com/20131018619/package-management-breaks-3000-apps-on-haikuware.

Note that while I agree with some of his points I completely disagree with his attitude and actions toward the Haiku community. He’d probably still be pissed if any package management at all existed… because it deprived his websites of traffic and thus any control and or tiny profits he felt entitled to over the Haiku project.

Also he was not really a developer… nor one of the developers that pretty much got burned out over the pacakgefs fiasco.

The hpkg files are geberated for the pms and are from beginning writeprotected. Started past alpha 4.1. I think you mean old beos packages, but they dies not support the package folders add after pms included. They are automatically install to home non packaged.

With including the pms many old programs are broken, this is true. Because they write files to his own folder, there was no really good structure the developer following.

The pms give a structure, people know to install files on the right position. Old files to non packaged. Some programs are broken, this is bad but the developers need to go with the time.

I miss call to power , corum 3, inside conatructor…

What about the programs that do not work with Haiku?
Moho 2.5?
Exposer?

What else? New thread about missing programs?

1 Like

Moho? The Animation tool? I think it runs well, last time i test it (for years).

Exposer? Hey @stippi why your old program not run anymore?

1 Like

Corrrect the package management system does give structure… but that structure should come from HaikuPorter not from bad assumptions in the package format.