From 564a7a1209b443825b4fb74013c7d8357278646b Mon Sep 17 00:00:00 2001 From: speedie Date: Fri, 14 Jul 2023 01:36:58 +0200 Subject: [PATCH] oops lmfao --- rss.xml | 126 -------------------------------------------------------- 1 file changed, 126 deletions(-) diff --git a/rss.xml b/rss.xml index a34f458..a180377 100644 --- a/rss.xml +++ b/rss.xml @@ -2036,131 +2036,5 @@ a good rest of your day.

]]> - - packr design goals - /blog.php/packr+design+goals - /blog.php/packr+design+goals - Thu, 01 Jan 1970 00:00:00 +0000 - - packr design goals - -

2023-07-08

- -

You may or may not be aware of it, but I started designing a package manager -back called packr early March this year. It was pretty poorly designed -however, and I don't think I had goals properly planned out. So I'm going to -talk about some of the goals I have in this blog post.

- -

Of course, they are subject to change, because I haven't implemented anything -yet. You can always watch the development -happen at the packr Git repository.

- -

If you have any suggestions on improvements, or think something I mentioned here -is stupid or unrealistic, please let me know. I am always open to suggestions -and potential improvements, no matter how ridiculous they may be.

- -

While I do plan on finishing this package manager and making it a reality, I'm -not sure when. Either way, what is listed here is going to document how I'm going -about designing it.

- -

You may ask, why design a new package manager? Well, I'm going to compare packr -ideas to existing package managers, but I don't like the design philosophy of -most package managers, and I also don't like the state of modern GNU/Linux.

- -

Source and binary hybrid

- -

One of the first key features I want to mention is that packr is going to be a -source and binary hybrid. That means both binaries and source based packages will -be available.

- -

pacman's main flaw is being based around binary packaging, and the finished packages -don't handle compilation whatsoever. This means the user cannot compile packages -himself without grabbing a PKGBUILD which will generate a binary package anyway.

- -

Portage fails here too. Portage is an excellent source based package manager, and -it is designed around source based packaging. It is definitely NOT designed for -binary packages though, and while it can be done it doesn't feel quite right.

- -

packr should install packages the same way, whether you're compiling a package -or installing a package someone else compiled for you. packr -i firefox should -install Firefox, regardless if it's a prebuilt binary or source code. This is going -to be achieved by having multiple versions in the repository at all times. Source -based packaging is going to be the primary packaging, and users (or maintainers) -will be able to submit prebuilt binaries in addition to those source based packages.

- -

Source packages can generate binary packages

- -

As I said, source based packaging is the primary way to handle packaging in the -repositories. However, because binary packaging is lacking on source based -distributions, I plan on solving this by allowing all source based packages -to be automatically compiled into a binary package after it has been installed -and compiled once.

- -

In practice, if one user compiles Chromium 113 from source, that user can generate -a Chromium 113 binary package using packr itself in seconds, and submit this -to the repository in addition to the Chromium 113 source package.

- -

Any user can submit source packages to a repository, and then other users can -fill the void by submitting a binary package based on that source package. Or, -of course a source and binary package could be submitted at the same time.

- -

Shell script based

- -

Packages should be POSIX shell script based. POSIX shell is a scripting language -everyone who uses UNIX like operating systems are eventually forced to learn. -Therefore, using this for packages is a great way to make packages as easy to write -as possible.

- -

If I end up writing it in C, one idea I have in mind is to have a shell script -read the package and send instructions to the main packr binary. This means the -only limitation is the shell itself. Either way, the packaging will be shell -script based. packr should be built around this fact.

- -

If I end up writing it in shell script, it would probably be even more extensible, -but perhaps a bit slower. It must still be faster than Portage.

- -

Free as in freedom; to install anything

- -

No, this is not about the FSF or free software. Packr packages should specify -if they make network requests, if they read files from the disk, if they need -superuser permission, programming language, dependencies, and so on. Think -Android. On Android the user is able to read what permissions the program -requires before installing it. That's an important part of packr packaging.

- -

Packages also need to specify licensing. This allows the user to make a decision -on whether or not he wants to use a software under the license. When a package is -installed, the user should (optionally) be notified of any antifeatures, the -aforementioned permissions such as network requests, and make a decision based on -that.

- -

If the user only wants to use GPL licensed software, he can. If the user -hates Richard Stallman and doesn't want to use anything GPL licensed, he can do -that too. If he wants to run Microsoft spyware and use a proprietary kernel, he -can do that too. The package manager should not prevent any of these things -unless the user wants it to.

- -

Extensible

- -

packr should be hackable and extensible. It should interact with other programs -and it should use existing programs where the existing solutions are good. -Don't reimplement packaging, or signing or repositories. Git should be used -for repositories, PGP signatures and checksums should be used for signing -packages, packages should be tarballs containing a shell script packr reads, -and for binary packages it should contain the main binaries too.

- -

Source packages designed to be recompiled

- -

Categories

- -

Repositories are just Git repositories

- -

PGP signing

- -

Conclusion

- - ]]> - -