🦸‍♀️ [OFFICIAL] Talk about Development 🦸‍♀️

[BaseMax]

Hi,

The DonyaOS is not yet ready and complete and we need the help of others.

Here's a chat room.

We can talk about the tasks we want to work on here.
And set a development path for ourselves.

Study and research can be one of the things that will always be needed in this project.

Please state if something goes wrong.
I appreciate you.

[BaseMax]

At this point, we have a script that can generate a new Linux distribution and produce .ISO image file.
https://github.com/DonyaOS/Donya/blob/815216b91e7df81c9d3aebc1217cd9a2b3d698b3/donya.sh

But this is not enough.

We need to separate the scripts and have such a separate file. (Not a single .sh file)

For example, Scripts:

• Downloading dependency files (Maybe someone has these file in their PC)
• Compile kernel, base
• Compile OS/BusyBox and other packages
• Generate .ISO image file

Also Makefile can help to compile quickly.

With Donya's package manager, I'd suggest a packaging system like KISS Linux (here's an overview: https://k1ss.org/package-system). What did you have in mind?

OK, with package management, this is what I had in mind—just a suggestion, I'm not entirely sure what your plans are:

We make a repository in the DonyaOS GitHub organization, and we call it packages or something to that effect. This will be the default source of packages in the package manager. Then, the package manager (which I'll call dpak until we come up with a proper name) will look for packages within that GitHub repository, at the root, by filename; so if we were to do something like: dpak install ExamplePackage, then dpak would read the data in the ExamplePackage.yml file at the root of the packages repository. This is similar to how the Homebrew package manager on macOS works.

Each package file in the repository will have several standard data fields, which I suggest we represent in YAML. These fields will be description, license, homepage, dependencies, binary (optional), and install. The package manager will show the package metadata (including the list of dependencies) before prompting the user if they want to install (like with APT). The install variable is a series of commands which will be ran by the system to get the package installed, useful for if the package is compiled (like how Gentoo handles packages), not a binary. In the event a package is binary-only, then the binary variable will point to the URL of the binary release, and then dpak will simply install it into the system.
Here's an example of a package called dlib; stored in DonyaOS/packages/dlib.yml:

description: "C++ library for machine learning"
homepage: "http://dlib.net/"
binary: "http://dlib.net/files/dlib-19.21.tar.bz2"
license: "BSL-1.0"
dependencies:
- cmake
- jpeg
- libpng
- openblas
install: |
  git clone https://github.com/davisking/dlib.git
  cd dlib-master
  mkdir build
  cd build
  cmake ..
  cmake --build . --config Release

This package manager model has several key differences over currently existing package managers:

1. It's simple—package repositories are easy to create, because they're just GitHub repositories
   • APT and Snapcraft struggle greatly in this department. Packaging software, and then publishing it into a repository, is a difficult process for developers who want to get their work installed via those package managers. Moving everything to a simple, GitHub-centric system will make publishing easier.
2. It allows for compiling packages rather than just getting binaries
   • This is only really seen in Gentoo nowadays. Making a simpler alternative to Portage is a good idea.
3. Greater GitHub integration; by making each software source a GitHub repository, it will force software publishers to become familiar with the open-source ecosystem, particularly if they wish to publish in the primary DonyaOS package repository. This promotes open-source development.

[BaseMax]

Thanks for your suggestion.
I did create packages repository in this organization.

https://github.com/DonyaOS/Packages

[BaseMax]

We need to design the package manager software.
Something similar to apt in ubuntu, pacman in Arch, pkg in FreeBSD.

I think GoLang is a good choice for this purpose.
C is also good.

Easy command line is very important.

We can use an alias:

• i for install.
• u or r for uninstall and remove
• s for search

For example:

d i php ; install php version 7.1
d i php7.4 ; install php version 7.2
d i gcc ; install gcc

d s php ; search all package with php perfix

d r php ; remove php package
d r php* ; remove all php prefix package

d i php* ; install all php prefix package

Display loading while downloading and package information before installing is a good feature.
Centos has this feature as well.

Ubuntu apt has a bad feature, this forces you to remove lock files if you stop this using ctrl+x, ctrl+c etc.

[BaseMax]

Hi,

Does anyone want to work on the package manager or package service? @sudo-corvus @limeschool Or others
We welcome this help.
I think GoLang is a good choice for this purpose.

Please tell me your comment.
Thanks,

[BaseMax]

PackageManager:
It's a client software, this should be installed at DonyaOS in default.
https://github.com/DonyaOS/PackageManager

Packages:
This is an API.
This is a web service, PackageManager will get his data from this repository.

https://github.com/DonyaOS/Packages

---

For example: If PackageManager wants to search in packages list, should get a list of packages from the Packages repository. and save this as a cache.

I think we can host packages files in GitHub.
Otherwise, we can create a server and host on that.
No problem with this.

[amir-shiati]

Hey @BaseMax i'm familiar with GoLang and i can help you guys with this!
Just let me know where to begin...

[BaseMax]

Hey Amir, @amir-shiati
Thanks for letting me know you agree to work on it.
I gave you full access. Therefore, you can submit and send changes in the desired repository without any permission.
Thanks,

I'm not familiar with Go or C. I'll try to make my own package manager in D, and then we can compare and pick which is best.

EDIT: D was not a good choice. Writing it in C# right now. It should perform rather well, with the time to complete an operation being almost entirely package-dependent and not noticeably impacted by any overhead.

[prince-dsd]

I will take this up in C I have been going through RPM to understand the process

[BaseMax]

Hi,
@amir-shiati is working to create Package Manager.
Can you please start working on the Packages repository? @sudo-corvus, and @limeschool

[prince-dsd]

all right on it @BaseMax