DonyaOS/PackageManager

πŸ¦ΈπŸΏβ€β™€οΈ [OFFICIAL] Development of the Donya Manager Package πŸ¦ΈπŸΏβ€β™€οΈ

BaseMax opened this issue Β· 26 comments

Hello everyone,

We discuss about development process of Donya Package Manager.

For first version, We will use Go as main programming language of package manager.

I look forward,

Core team of Donya Package Manager:

And others:

I invite Parham to manage this Repository. We need his help

Current project mostly written by @amir-shiati and some parts by @jbampton.

Donya Package manager needs to be connected directly to the Packages repository.
Therefore, there is a one-way communication between these two reservoirs.

We need your help to make a more accurate decision about design API or download Package as a cache mechanism:
https://github.com/DonyaOS/Packages

@BaseMax Thanks for mentioning these informations. Is there any final document on its architecture?
@amir-shiati and @BaseMax Do you agree to migrate to golangci-lint with drone-ci?

Thanks for your suggestion.

golangci-lint is a good library for working with yaml format with cache support.
CI helps us keep software safe with fewer problems.

https://github.com/golangci/golangci-lint
https://drone.io/

We have a diagram prepared by Amir for the packaging manager:
DonyaOS/Donya#5 (comment)

Yes exactly. I can change the structure to support these. Golangci-lint improves the go code by showing common issues.

Good job.

If we keep packages without category directory, We can directly access to yml file. (Category directory means: core, extras, ...)
https://raw.githubusercontent.com/DonyaOS/Packages/master/core/NAME_OF_PACKAGE/package.donya
or even:
https://raw.githubusercontent.com/DonyaOS/Packages/master/NAME_OF_PACKAGE/package.donya

For example:
https://raw.githubusercontent.com/DonyaOS/Packages/master/core/curl/package.donya

But, It's not all. We also need a search ability in the Donya package manager.
So we have two way, A always running Webservice. Or a cache mechanism to keep Packages repository in temp.

GitHub request rates is limited, So it's not suitable for Production Webservice.
DonyaOS/Donya#5 (comment)
DonyaOS/Donya#5 (comment)

Anyway, No problem. We have some servers. so can get help, And can serve in own domain/server.

If you can write another Go program to search in packages on a port.
Using Nginx I can run it on its server.
It's another program and can maintain on Packages repository.
In this case, we will need a Domain. (Next step, not now)

Update:
With SSH we can keep files on the server up to date:
DonyaOS/Donya#5 (comment)


What's your suggestion and what's best for this?

@1995parham Hey Parham you are definitely more experienced in golang than me so take the lead on this project and just let me know what can i help you with.

@BaseMax
why not using a Paas for the webservice?
it's easier to deploy our service and maintain it and i think it's cheaper...
e.g: checkout heroku , fandogh

Good suggestion. @amir-shiati
If their free plans are suitable, We can use them as well. https://www.heroku.com/pricing

And one more point:
heroku.com is an American company.
I'm not sure they have blocked services for Iranian visitors! (Or even the future)

I think in the end we need to have a web service for our packages but for the beginning, we can write the installation phase with Github then continue to have the search functionality and web service. Is there any specification for the package structure?

We can use a scripting language like javascript embedded in Go for having more functionality in our package definition.

Having more functionality

It's a very good idea.

It may help us a lot in some cases where there is library interference.

Hi,

What's up? @1995parham
Thanks for anyone posting a report of work here.
I would gratitude.

Cheers,

I am investigating the ways that we can implement the package manifest. Meanwhile at the weekend (Thursday and Friday) I will start refactoring the repository.

@BaseMax What do you think about creating teams (like a team for the package manager that you have created here) then continue our discussion using Github discussion in the team?

Hi Parham,
I'm agree with it.
In the fact, I'm not sure. Because issues are fully public and teams are not visible by guests.
What do you think? @1995parham
Anyway, I invited you and linked this repository in the team.

I think we can do the discussion in the Github chats then report the conclusions for further notes here. In this way there are fewer conversations to read by gusts in the issues.

I am trying to set up a PoC with goja and start creating a simple package manifest.

Hi,
Thanks for last update. @1995parham
We look forward to hearing from you.

Thanks for the follow-up. The source code structure is ready if you want we can finalize our manifest and I will implement it shortly.

@BaseMax As a first question for designing manifest, Doya will builds packages locally and needs a build specification. Am I right?

Hello everyone,
Another week passed. Please release first version and your changes. @1995parham
We look forward to seeing.


A figure how yay works in Arch:

[max@base]$ yay networkmanager-l2tp

1 aur/networkmanager-l2tp 1.8.2-1 (+101 0.45) 
    L2TP support for NetworkManager
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 1
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:1]  networkmanager-l2tp-1.8.2-1

  1 networkmanager-l2tp                      (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> n
:: PKGBUILD up to date, Skipping (1/1): networkmanager-l2tp
  1 networkmanager-l2tp                      (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> n
:: (1/1) Parsing SRCINFO: networkmanager-l2tp
==> Making package: networkmanager-l2tp 1.8.2-1 (Sat 03 Oct 2020 03:49:23 PM +0330)
==> Retrieving sources...
  -> Found NetworkManager-l2tp-1.8.2.tar.gz
==> Validating source files with md5sums...
    NetworkManager-l2tp-1.8.2.tar.gz ... Passed
==> Making package: networkmanager-l2tp 1.8.2-1 (Sat 03 Oct 2020 03:49:25 PM +0330)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found NetworkManager-l2tp-1.8.2.tar.gz
==> Validating source files with md5sums...
    NetworkManager-l2tp-1.8.2.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting NetworkManager-l2tp-1.8.2.tar.gz with bsdtar
==> Starting prepare()...
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: linking file 'm4/libtool.m4'
libtoolize: linking file 'm4/ltoptions.m4'
libtoolize: linking file 'm4/ltsugar.m4'
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:15: installing './compile'
configure.ac:28: installing './config.guess'
configure.ac:28: installing './config.sub'
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
Makefile.am: installing './depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc-ar... gcc-ar
checking for gcc-ranlib... gcc-ranlib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... (cached) gcc-ranlib
checking command to parse /usr/bin/nm -B output from

And a screenshot, to show text have special color: (Green, Red, Blue)

demo1
demo2

King Regards,
Max

Yeah, this mechanism run commands in local system.
To compile packages in own local system.

But can also download a binary file and copy/paste it.

wget https://raw.githubusercontent.com/DonyaOS/Packages/master/core/curl/curl-linux-x86_64.app
mv curl-linux-x86_64.app /usr/bin/curl

And this depends on package scripts.

@BaseMax Thanks for mentioning this information. So we need to build the project with our script just like yay. So I will add the following into the repository:

  • Instal function in our script that is called on install command to run the build procedure.
  • A function in our script that returns the repository address, are you ok with this? by this we can have a similar structure to AUR.

P.S. By our script I mean a script that I parse with our DonyaPackageManager and written in javascript.

@BaseMax I have complete the first version of our installation script:

version = "13"
arch = "amd64"
sources = [
	"https://httpbin.org/bytes/" + version,
]
function install() {
	console.log(this.go)
	console.log(this.version)
	console.log('Hello World')
	console.log(this.files[0])
	exec.run(['cat', this.files[0]])
}

It has install function that is run for installation. sources contains the required sources that are downloaded as temporary files for install script. If you want I can document it into README.