oops lmfao
This commit is contained in:
parent
ebe638441e
commit
564a7a1209
126
rss.xml
126
rss.xml
|
@ -2036,131 +2036,5 @@ a good rest of your day.</p>
|
||||||
]]>
|
]]>
|
||||||
</description>
|
</description>
|
||||||
</item>
|
</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>
|
</channel>
|
||||||
</rss>
|
</rss>
|
||||||
|
|
Reference in a new issue