Skip to content
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

๐Ÿฆธ๐Ÿฟโ€โ™€๏ธ [OFFICIAL] Development of the Donya Manager Package ๐Ÿฆธ๐Ÿฟโ€โ™€๏ธ #8

Open
BaseMax opened this issue Sep 11, 2020 · 26 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@BaseMax
Copy link
Member

BaseMax commented Sep 11, 2020

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,

@BaseMax
Copy link
Member Author

BaseMax commented Sep 11, 2020

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.

@BaseMax
Copy link
Member Author

BaseMax commented Sep 11, 2020

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

@1995parham
Copy link
Member

@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?

@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

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/

@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

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

@1995parham
Copy link
Member

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

@1995parham 1995parham added the documentation Improvements or additions to documentation label Sep 12, 2020
@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

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?

@amir-shiati
Copy link
Member

@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.

@amir-shiati
Copy link
Member

amir-shiati commented Sep 12, 2020

@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

@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

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)

@1995parham
Copy link
Member

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.

@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

We can apply any suggestions you have.
It can be interesting even if you are considering another custom structure.

https://github.com/DonyaOS/Packages/#package-structure

Embedded Interpreter:

And more at: https://stackoverflow.com/a/27496999/10096230

@BaseMax
Copy link
Member Author

BaseMax commented Sep 12, 2020

Having more functionality

It's a very good idea.

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

@BaseMax
Copy link
Member Author

BaseMax commented Sep 14, 2020

Hi,

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

Cheers,

@1995parham
Copy link
Member

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.

@1995parham
Copy link
Member

1995parham commented Sep 15, 2020

@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?

@BaseMax
Copy link
Member Author

BaseMax commented Sep 16, 2020

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.

@1995parham
Copy link
Member

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.

@1995parham
Copy link
Member

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

@BaseMax
Copy link
Member Author

BaseMax commented Sep 24, 2020

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

@1995parham
Copy link
Member

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.

@1995parham
Copy link
Member

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

@BaseMax
Copy link
Member Author

BaseMax commented Oct 3, 2020

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

@BaseMax
Copy link
Member Author

BaseMax commented Oct 3, 2020

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.

@1995parham
Copy link
Member

1995parham commented Oct 3, 2020

@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.

@1995parham
Copy link
Member

@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.

@jbampton jbampton changed the title [OFFICIAL] Development of the Donya Manager Package ๐Ÿฆธ๐Ÿฟโ€โ™€๏ธ [OFFICIAL] Development of the Donya Manager Package ๐Ÿฆธ๐Ÿฟโ€โ™€๏ธ Jun 6, 2021
@jbampton jbampton self-assigned this Jun 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Donya Package Manager
  
Awaiting triage
Development

No branches or pull requests

4 participants