Nor really no… its a file permission not a read only filesystem that’s completely different.
My argument is a million light years from saying there are no useful applications for Haiku.
Earlier you wrote: “you know every well there has been an endless stream of BeOS apps that don’t work after packagefs was implemented”
The “endless stream” appears to consist of a program to save you from buying a well-known book.
Let me have your address and I will send you a book token so you can buy the book for yourself.
Then perhaps we can debate something of real significance.
If this isn’t a debate of any significance to you (perhaps packagefs or no it would not affect you) then just bow out thanks no need to get snippy about what applications I do or do not use.
And no that is not the only one, just an easy one to point out.
Also imagine for a moment…an electronic Bible is seachable… wonder of wonders -_- why you would presume that someone using an electronic Bible program would preclude them from owning a hardcopy I have no idea… but that is par for the course with the rest of the arguments lobbed back in this thread.
I tried the app because it is on Polyglot for translation.
To be honest, it is more than a reader for a single book. The only thing well known about this book is the title that we are commonly using and the app allows comparison between different versions of scriptures sometimes published under different names.
It would be impossible to get all these versions, some are certainly unavailable, others unaffordable.
Can we ignore that particular app since the problem was not related to packagefs at all? So do we agree that you keep saying there is an “endless stream” of broken apps and yet are unable to find a single one?
That settles the discussion for me. I will stop commenting here until someone can show me a single example of an app that’s actually broken because of packagefs.
And to do my side of the work here is a short list of things that were made possible with packagefs, and without which I dare to say Haiku would now be as dead as Syllable or SkyOS:
- Porting LibreOffice
- Porting Qt and many Qt apps (like it or not, it is a stopgap solution until we get more native apps)
- Keeping ffmpeg up to date, and managing to build it using gcc8 even for the gcc2 version of Haiku
- Proper, maintenable, versions of ported games that don’t each come with a broken version of libSDL and occasionally replace other system libs and make your system unbootable
- In my personal case, many tools for cross development for embedded systems (ARM, AVR/Arduino, various 8bit CPUs)
I’m pretty much fully convinced that this was totally worth the hundred megabytes of RAM it uses currently. And I’m also convinced that if this was really a problem, someone would be busy optimizing it. But at the moment I think I have other priorities, given that less than 10% of the RAM on my computer is used.
5 Likes
You’re absolutely right. Ported programs from NIX require package management. It’s very difficult without it.
Ported programs are also good today. It’s better to have these than none.
I would like some changes in package management:
- In the / boot / system folder there should be packages that are directly related to Haiku.
- other programs should be automatically installed in another folder (for example /boot/application).
In this case, I can get a “clean” system by simply removing all the packages from / boot / application.
And dreaming of Application Bundles in Haiku like macOS. May be Application Bundles with universal binary support. There is nothing easier than installing an application by simply copying it to the / boot / apps folder for example. And this application will include all the necessary libraries.
1 Like
I my eyes it would be the best way to have a packages folder in home (user files). Then we can use this later for multiuser support. If one remove all files from home/packages for example, he does not destroy the system. And if you have more then one user on this pc (a child for example) your data are save too.
It’s better to have an installation diagram:
- /boot/system - only system Haiku packages
- /boot/application - packages for all users
- /boot/home/ … - packages for each user
But then you need the possability to select the target install position (application or home/packages). Then to much will be installed in here and there. I think this is not clean enough. Better to have scritly folders and the user does not need to decide. Only admin
You can create your own extra package directories if you want to, I think.
And yes, for now /boot/home/config/packages can be used a bit like that (we will reconsider things when we go multiuser, probably, but for now we decided that the 3rd package directory was not needed. Before package management was added there used to be a /boot/common directory similar to what you describe.
Universal binaries were proposed but not adopted, simply because they make the packages larger. I think they work well for Apple because they use them as a way to transition from one architecture to another, but in our case we plan to support and keep supporting multiple architectures all at once. There would be a lot of complaints that the m68k, sparc, and powerpc code wastes a lot of space for no reason. Also, the difference of compiler versions (gcc2/gcc8) can make this more complicated than it would look at first.
As for bundles, I think it has a major problem that the dependencies are included in the bundle and so they can’t be updated for security fixes and the like. But, you can copy an hpkg file in /boot/system and the package daemon will pick it up and install missing dependencies as needed. I think this is close enough in terms of usability. And it turns out, it’s even simpler to double click the package and install it through HaikuDepot, so I don’t know if we will keep this “copy to install” feature forever (no plans for short-term removal, but if we’re talking about simplifying the package system, it’s one of the features I wouldn’t, after all, consider essential). For now it’s there to stay however.
And, nothing prevents you making your hpkg file “bundle style”. All you have to do is include the dependencies inside it, preferably in apps/yourApp/lib/ so that it doesn’t interfere with other applications. That would work just fine. It’s just that people making the packages, for the most part, decided that haikuporter and the ability to get their dependencies updated made their life simpler. The non-haikuports repositories are also available and we may consider enabling them in the default install if 1) there is some demand for it (as far as I know no one asked for it so far) and 2) we are confident with the way they are managed and the quality of the packages (that they will not break your system, intentionally or not, and that there is some policy in place to manage security updates of dependencies, for example).
The package system on its own is able to do many things, it just happens that the haikuports way has been very popular, but it doesn’t have to be the only one way. In fact this is not at all what we expected at the start, originally we thought that bebits/haikuware or something alike would provide a repository for native software that wouldn’t involve writing complicated recipes (you can pretty easily create a package without the haikuporter infrastructure, calling the “package” command directly, it’s not a lot more complicated than creating a zip file for your software), and that haikuports would only manage ported software with the complex dependencies, etc. However, this didn’t really happen.
The outcome is still somewhat healthy however, because the result is a lot of work on HaikuArchives which helped bring many of the old BeOS apps to 64bit systems and getting their sources released and under appropriate licenses which allows long term maintenance and updates. We would have preferred for the original authors to update and repackage their apps, but let’s be honest, most of these apps were last updated 20 or 15 years ago and developers moved on to other platforms.
4 Likes
Sometimes it is better to include libraries in the program.
I would prefer to have an “application bundle” without using hpkg. Just a special folder with full access to change it. But the user in Tracker sees it as a single file. And launches it the same way. I think you know how to do it on macOS or RISCOS.
Write access to the “application bundle” is useful for those programs that can change themselves (Lazarus IDE as a good example) or put scripts, plugins, etc. in the “application bundle”
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.