My Alternative Package Tool and Ports System for FreeBSD

[Zare]

I don't see how that general quote affects the fact that you're developing a replacement/alternative for a system component while not being in sync or affiliated with FreeBSD Foundation and not taking into the account the base design of FreeBSD, and the cooperation with the existing ports and packages system. This here :

args = ["--prefix=/usr",

If this results in what I think it does, package installation under /usr, it's a total fkin haram as far as I'm concerned.

As I already wrote I have a positive view of your project but due to what I've practically explained it will never be a prospect for pkg/ports alternative or possible next-gen replacement; pkg is a next gen replacement, I don't see that as set in stone, but your project as you're outlining it, is not it. Witty out of context quotes from some relevant people are not going to change that. Logging off from thread, good luck in your endeavor.

 

[zester]

I don't see how that general quote affects the fact that you're developing a replacement/alternative for a system component while not being in sync or affiliated with FreeBSD Foundation and not taking into the account the base design of FreeBSD, and the cooperation with the existing ports and packages system. This here :



If this results in what I think it does, package installation under /usr, it's a total fkin haram as far as I'm concerned.

As I already wrote I have a positive view of your project but due to what I've practically explained it will never be a prospect for pkg/ports alternative or possible next-gen replacement; pkg is a next gen replacement, I don't see that as set in stone, but your project as you're outlining it, is not it. Witty out of context quotes from some relevant people are not going to change that. Logging off from thread, good luck in your endeavor.

You’re still arguing from a premise I don’t accept. I am not required to be affiliated with the FreeBSD Foundation, nor to design around the historical constraints of ports/pkg, in order to build an alternative system. That premise alone is false. As for the /usr example: that is a configuration detail, not a design mandate, and it’s already been stated elsewhere that the system can live entirely outside the base system. Treating an illustrative snippet as proof of architectural intent is simply incorrect. More importantly, I am not claiming this is the next-generation replacement for ports/pkg, nor seeking that endorsement that framing is yours, not mine. This is an alternative built around different invariants and tradeoffs. If you’ve already decided that only systems that evolve within the existing ports/pkg model qualify as “legitimate,” then we’re not having a technical disagreement, we’re having a philosophical one and I’m fine leaving it there.