HyperWiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
en:manual:contrib:package_creation [2024/08/15 13:17]
throgh [Creating packages for Hyperbola] 		en:manual:contrib:package_creation [2024/08/19 16:44] (current)
throgh [The decisions behind: Are there disadvantages?]
Line 11: Line 11:
   * knowledge about file-handling and folder-structures under GNU/Linux / UNIX   * knowledge about file-handling and folder-structures under GNU/Linux / UNIX
   * knowledge about handling configuration-files and commenting in or out their values   * knowledge about handling configuration-files and commenting in or out their values
-  * handling privileges for users and groups under GNU/ Linux / UNIX+  * handling privileges for users and groups under GNU/Linux / UNIX 
 +  * handling services and especially setup a webserver under GNU/Linux / UNIX (//for your own repository//)
  
 If you do not have any knowledge within those named fields, this guide is not meant for you at this moment. If you do not have any knowledge within those named fields, this guide is not meant for you at this moment.
  
 <note warning>Hyperbola is not meant as system to be used by people beginning with Unix and Unix-like systems. Surely you can do this, but this is combined with a meant learning-curve for your own **technical emancipation**. Please understand that we need to define boundaries about what we are able to manage, maintain and explain. Going that deep into every detail is not possible and therefore we kindly ask for your own willingness reading into details and test commands for example on your own, where you are not sure for the moment. We would be happy if you share later on your knowledge or add more information here within the article.</note> <note warning>Hyperbola is not meant as system to be used by people beginning with Unix and Unix-like systems. Surely you can do this, but this is combined with a meant learning-curve for your own **technical emancipation**. Please understand that we need to define boundaries about what we are able to manage, maintain and explain. Going that deep into every detail is not possible and therefore we kindly ask for your own willingness reading into details and test commands for example on your own, where you are not sure for the moment. We would be happy if you share later on your knowledge or add more information here within the article.</note>
 +
 +===== The decisions behind: Are there disadvantages? =====
 +
 +You may ask for sure: Do I really need all of this and manage packaging? The clear answer here is surely: No, you do not need to. But in fact you will also have to manage all the compiled and installed data on your own. Minimizing that effort is to create as said clear packaged software and data for you to install, remove, up- or downgrade all the time again on your own will with the clear point of knowledge what you are doing and what data is next added to your system running.
 +
 +Are there disadvantages? Not really, besides you learn much more about the file-system and its structures. It just depends on your will doing so. If you have no interest? Sure, it is your choice doing so. But you can also share the scripts for others to review them, helping you with possible problems running software and in the end you can give also something back when you share your package-script and the files around for others to understand, learn, modify and share them again. Or you get hosting your own repository offering software and ports for others to download and install? As said: That is your decision, but we believe clearly within the model to share information, data and more, giving something back. We believe not within seeing free, libre software only as "gratis offered software" including full-time support at any given point. If you want that, Hyperbola is not the project and system for you and we kindly ask you to search for a different solution.
  
 ===== Generic overview for the usage ===== ===== Generic overview for the usage =====
Line 459: Line 466:
  
 Those split definitions are only possible and needed when the software itself supports different definitions at time building and you have the intention to offer also those as dedicated package. Those split definitions are only possible and needed when the software itself supports different definitions at time building and you have the intention to offer also those as dedicated package.
 +
 ===== Setup for a clean build-environment ===== ===== Setup for a clean build-environment =====
  
Line 513: Line 521:
  
 We have now possible environments named **x86_64** and **i686**. At this point it is needed to mention that you can clearly choose also different names for your environments when creating them. Those are only first recommendations resulting from the experiences made. We have now possible environments named **x86_64** and **i686**. At this point it is needed to mention that you can clearly choose also different names for your environments when creating them. Those are only first recommendations resulting from the experiences made.
 +
 +<note important>Please note that you can only use //32bit// and //64bit// on a system supporting //64bit//. Systems only supporting //32bit// can also only support //32bit// as possible **chroot**.</note>
  
 You can update and synchronize your chroot-enviroments with the following commands: You can update and synchronize your chroot-enviroments with the following commands:
Line 530: Line 540:
 <code> <code>
 doas libremakepkg -n i686 doas libremakepkg -n i686
 +</code>
 +
 +===== Creating your own repository =====
 +
 +You can create your complete own repository for local or remote usage. The difference in between is for sure that local usage means only yourself as user for packages while remote usage includes everyone else. So let's assume that you have created now two packages:
 +
 +<code>
 +ls
 +armagetronad  jumpnbump
 +</code>
 +
 +In every folder listed is a compiled package ready for its further usage. For armagetronad this may be:
 +
 +<code>
 +armagetronad-0.2.9.1.0-1-i686.pkg.tar.lz
 +</code>
 +
 +Let's copy all package-files to a newly created folder where our database will reside:
 +
 +<code>
 +cp ./*.pkg.tar.lz /var/local/mypkgs
 +</code>
 +
 +We enter now the folder for our new repository:
 +
 +<code>
 +cd /var/local/mypkgs
 +</code>
 +
 +And afterwards create our package-database:
 +
 +<code>
 +repo-add mypkgs.db.tar.lz *.pkg.tar.lz
 +</code>
 +
 +Example for resulting output:
 +
 +<code>
 +# repo-add mypkgs.db.tar.lz *.pkg.tar.lz
 +==> adding package 'armagetronad-0.2.9.1.0-1-i686.pkg.tar.lz'
 +  -> Computing checksums...
 +  -> Creating 'desc' db entry...
 +  -> Creating 'files' db entry...
 +==> adding package 'jumpnbump-1.61-2-i686.pkg.tar.lz'
 +  -> Computing checksums...
 +  -> Creating 'desc' db entry...
 +  -> Creating 'files' db entry...
 +==> Creating updated database file 'mypkgs.db.tar.lz'
 +</code>
 +
 +Now you can add your own repository to your //pacman.conf// under ///etc/pacman.conf//:
 +
 +<code>
 +[mypkgs]
 +Server = file:///var/local/mypkgs
 +</code>
 +
 +Or you can share this via HTTPS / HTTP:
 +
 +<code>
 +[mypkgs]
 +Server = https://<your-ip-address>/mypkgs
 </code> </code>