Create ports tree

Umm, I dont think its exactly wise to put things like doom in the sysroot, you should create a ports tree where you can access these packages using the internet to download the source, then compiling it(and create eth drivers). Just a thought.
(I also dont want to cherry pick what commits I want to add to uwux, im building other projects rn)

It would be nice to have a config.toml where we could enable or disable ports that we want to build. For example:

# ---- config.toml -----
[sysroot]
# by default no ports will be enabled.
ports = ["gcc", "rust", "ripgrep"]

and this config file will be read by aero.py when called with --sysroot and will make xbstrap only build those enabled ports. Pretty nice idea actually.

It would be nice to have a config.toml where we could enable or disable ports that we want to build. For example:
# ---- config.toml -----
[sysroot]
# by default no ports will be enabled.
ports = ["gcc", "rust", "ripgrep"]
and this config file will be read by aero.py when called with --sysroot and will make xbstrap only build those enabled ports. Pretty nice idea actually.

Hmm, that would seem amazing, but I think there should be a equivalent of a "classical" ports tree or something more intuitive that would use "cutting edge" sources.

Hmm, that would seem amazing, but I think there should be a equivalent of a "classical" ports tree.

We could have a config.toml.example which will be copied over to config.toml (if it does not exist) where config.toml.example will contain the classic ports and the actual config.toml which we can modify will then be in the gitignore.

Hmm, that would seem amazing, but I think there should be a equivalent of a "classical" ports tree.

We could have a config.toml.example which will be copied over to config.toml (if it does not exist) where config.toml.example will contain the classic ports and the actual config.toml which we can modify will then be in the gitignore.

Maybe add a cli on top of that for better user experience...

Maybe add a cli on top of that...

What do you mean by that? It will all be handled by aero.py

Maybe add a cli on top of that...

What do you mean by that? It will all be handled by aero.py

I mean for example when running *BSD on a system you can install and compile ports on the system without recompiling *BSD(https://www.freebsd.org/ports/).

Clarification: the source of the ports is not installed on the system, its only installed while in the dir of the port(its quite confusing to me too, basically im asking for something like portage).

Maybe add a cli on top of that for better user experience...

aero.py is the CLI though 🤔

Maybe add a cli on top of that for better user experience...

aero.py is the CLI though thinking

I cant run ./aero.py inside a default aero install though :^) You cant download, install and compile ports inside aero yet though you can do that while compiling aero. Look at the examples I showed, *BSD ports tree and portage(its very hard to explain unless youve actually used it).

You cant download, install and compile ports inside aero yet though you can do that while compiling aero. Look at the examples I showed, *BSD ports tree and portage(its very hard to explain unless youve actually used it).

Oh, you want something similar to a package manager, which would download and build ports inside of aero itself? I think that wont be a thing until we can successfully run GCC inside of aero, which will probably take a while :^) Definitely something I would keep in mind though.

Oh, you want something similar to a package manager, which would download and build ports inside of aero itself? I think that wont be a thing until we can successfully run GCC inside of aero, which will probably take a while :^) Definitely something I would keep in mind though.

Yep! A "proper" package manager like cargo/pacman would be used for "stable" packages and the ports would be used for bleeding edge, "commited 2 seconds ago" commits.

Considering you're already using xbstrap under aero.py, and you're using mlibc as libc, may I recommend xbps as a package manager? It's almost fully working on Managarm, which means the libc side of things is mature enough to run this.

Considering you're already using xbstrap under aero.py, and you're using mlibc as libc, may I recommend xbps as a package manager? It's almost fully working on Managarm, which means the libc side of things is mature enough to run this.

That looks good, but a ports manager would reaaaly be appreciated.

Considering you're already using xbstrap under aero.py, and you're using mlibc as libc, may I recommend xbps as a package manager? It's almost fully working on Managarm, which means the libc side of things is mature enough to run this.

That looks good, but a ports manager would reaaaly be appreciated.

What is the difference between a ports manager and a package manager? What you want is a way for end users to download and install packages. Preferably those are prebuilt for Aero, not gentoo style right? Then they are the same? If you do want gentoo style, port xbstrap and done

Keep the issue open, it's not resolved yet.

Maybe add a cli on top of that...

What do you mean by that? It will all be handled by aero.py

this reminds me, aero.py is kinda annoying to use with just flags because some flags only apply to certain things. it would be nice to have subcommands as well as flags.

Navigation Menu

Repository navigation

Create ports tree #37

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Create ports tree #37

Description

Activity

Andy-Python-Programmer commented on Jan 16, 2022

YusufKhan-gamedev commented on Jan 16, 2022

Andy-Python-Programmer commented on Jan 16, 2022

YusufKhan-gamedev commented on Jan 16, 2022

Andy-Python-Programmer commented on Jan 16, 2022

YusufKhan-gamedev commented on Jan 16, 2022

48cf commented on Jan 17, 2022

YusufKhan-gamedev commented on Jan 17, 2022

48cf commented on Jan 17, 2022

YusufKhan-gamedev commented on Jan 17, 2022

Dennisbonke commented on Jan 17, 2022

YusufKhan-gamedev commented on Jan 17, 2022

Dennisbonke commented on Jan 17, 2022

Andy-Python-Programmer commented on Jan 30, 2022

jwpjrdev commented on Sep 16, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions