oops lmfao
This commit is contained in:
speedie
parent
ebe638441e
commit
564a7a1209
126
rss.xml
126
rss.xml
|
|
@ -2036,131 +2036,5 @@ a good rest of your day.</p>
|
|||
]]>
|
||||
</description>
|
||||
</item>
|
||||
<item>
|
||||
<title>packr design goals</title>
|
||||
<link>/blog.php/packr+design+goals</link>
|
||||
<guid>/blog.php/packr+design+goals</guid>
|
||||
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate>
|
||||
<description>
|
||||
<![CDATA[
|
||||
<h1>packr design goals</h1>
|
||||
|
||||
<p>2023-07-08</p>
|
||||
|
||||
<p>You may or may not be aware of it, but I started designing a package manager
|
||||
back called <code>packr</code> 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.</p>
|
||||
|
||||
<p>Of course, they are subject to change, because I haven't implemented anything
|
||||
yet. You can always <a href="https://git.speedie.site/speedie/packr">watch the development</a>
|
||||
happen at the packr Git repository.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Source and binary hybrid</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>packr should install packages the same way, whether you're compiling a package
|
||||
or installing a package someone else compiled for you. <code>packr -i firefox</code> 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.</p>
|
||||
|
||||
<h2>Source packages can generate binary packages</h2>
|
||||
|
||||
<p>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 <em>after</em> it has been installed
|
||||
and compiled once.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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 <em>and</em> binary package could be submitted at the same time.</p>
|
||||
|
||||
<h2>Shell script based</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Free as in freedom; to install anything</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<p>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
|
||||
<em>unless</em> the user wants it to.</p>
|
||||
|
||||
<h2>Extensible</h2>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
<h2>Source packages designed to be recompiled</h2>
|
||||
|
||||
<h2>Categories</h2>
|
||||
|
||||
<h2>Repositories are just Git repositories</h2>
|
||||
|
||||
<h2>PGP signing</h2>
|
||||
|
||||
<h2>Conclusion</h2>
|
||||
|
||||
]]>
|
||||
</description>
|
||||
</item>
|
||||
</channel>
|
||||
</rss>
|
||||
|
|
|
|||
Reference in a new issue