> Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected t

> Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. You can already do all of that up until the "without having..."; and as I said in the article, someone could write a script for that in a matter of an hour; and of course a GUI in ... as long as it took to bikeshed ;) There is no technical limitation here. We have not implemented a GUI for it because, as I said, few users seem to want or need it. > Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. Why do you keep calling this "magic"? Packages in Haiku are file systems. This is in fact how AppImage also works, which you seem to like. Are you complaining about how AppImage is internally implemented? > My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies. No, it would not. It would indeed require magic on Linux because the tools that understand dependencies, where to get them, and interface with the user (e.g. apt) are separate from the tools that manage the actually installed packages (e.g. dpkg.) No such distinction exists on Haiku. In fact there is a screenshot in the linked article where probono dragging a package into the system packages directory, and the system automatically asked him if he wanted to install its dependencies. All that is missing from your usecase is a way to get these from a local folder instead of downloading them as is done right now. It would in no way be some "magic hack" that violates abstractions, good design, etc. like it would on Linux. > Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage? I already explained this: you can do it manually already by using the "mount" command. Support for it does not exist at the GUI level, and very few users requested it, so we (the development team, who are not paid to work on this, and have ~1-2 man-months total per month to spend on Haiku between the entire team) did not implement such a feature that less than 1% of people want. But once again, there is no technical barrier here and it is already possible if you don't mind CLIs. > There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree. So far, the "technical restrictions" you have referred to in this comment are actually incorrect, they are simply "there is no GUI" not "this is not possible with the present design." The one you referred to before ("can't modify packages") is also a restriction of AppImages, I believe? So I don't actually know what technical restrictions you are referring to at this point. > I really don't understand why you seem so intent on convincing me that my opinion is incorrect. You are perfectly welcome to dislike packages because you want to use .zips, or some other personal preference or the like. I am, however, intent as I said in the last comment on disagreeing with you when your opinion is "I don't like X because it can't do/does Y", when in fact X can or does not do Y, as is the case with most of your objections to the Haiku package management system thus far. > You're of the opinion that those are not significant, and I am of the opinion that they are. And which one of us has spent 5+ years both working inside said system as a developer, and on said system as a user, and in the community of said system with the other users who use said system on a daily basis, some even as a daily diver? > Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. No. That is not what my "in the minority" has (largely) meant. It has meant that "we did not implement X because few people seem to want/need X and we have very little time in the first place," i.e. if we had more time, we might have implemented X, and if someone sent us a patch that did X we would likely accept it; not "your usecase is not valid." > Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications. Correct. But you can add another hard-coded blessed path to the system with two lines of code and a recompile. We would almost certainly accept a patch that added blessed paths via a configuration file. (Again, this seems to be rarely needed or requested; this does not mean it is not a valid usecase, it means our precious little time will be spent first on more important things. Patches and/or sponsorships wanted.)