-
Notifications
You must be signed in to change notification settings - Fork 3
version 0.1, implementation of some features with priority label #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
added gui notification window
java and perl as options
|
the project also plans to introduce config for easy reproducible starting setup, the config would allow the user to utilize the features of the program in a fully autonomous manner |
the name is also used for display instead
|
the basic initial config as of this comment: {
"afi_conf": "iaacornus/Fedora-OSTree-Setup/devel/config/app_for_install.json",
"afu_conf": "iaacornus/Fedora-OSTree-Setup/devel/config/app_for_removal.json",
"tprepo-i": [
"rpm_rfusion_f",
"rpm_rfusion_nf",
"rpm_rfusion_tainted",
"rpm_rfusion_nf_tained",
"fp_flathub",
"fp_fed_oci",
"fp_kde",
"fp_gnome_nightly"
],
"cdrv-i": true,
"wq_ssd-d": true,
"toolbox-r": true,
"wayland_ff-e": true,
"ff_rpm-r": true,
"ppd-r": true,
"deep-sw": true,
"batt_thresh": 80,
"bpkgs-r": true,
"fish-s": true,
"fish-mod": {
"greetings": null
},
"rfusion-ri": true
}
|
thanks for the syntax!
thanks for the syntax!
I dont think recommending Flatpaks makes sense really.
minor changes and descriptions
mroe suggested rpms
the desktop env can be determined using some modules, hence theres no need to specify whether its kde or gnome replaced `i` with `add`, `r` with `rm`, `ri` with `radd` (reinstall)
added more configs, extended some names, reordered
added more configs, extended some names, reordered
|
I would say installing Flatpaks is also step 1. Somewhere I read it is not recommended to layer packages with the initial update, but I dont think adding repos could hurt. |
thats an interesting suggestion, but i agree that maybe we should commence a full system upgrade first before doing modifications and what not |
|
I think we should go away from the "as little as possible" approach. If we can build a custom image without client-side layering, why not do it perfectly? In the docker build on Github you can edit everything, place custom files and more. You can remove all those weird free codecs and drivers and replace them with working ones from rpmfusion for example. The process is like that:
|
the mechanism of program is described as follows:
some of the currently implemented features includes:
work in progress