web/jobcomm.md
2022-04-06 12:03:15 +00:00

4.2 KiB

Back to the top joborun wiki page

jobcomm repository

1 #### How it may work ####

This is in experimental phase and in great need of feedback.
Just like ArchLinux has the community repository for 3rd priority software, software that are neither part of the base essential system nor are they building (makedependencies) dependencies of the core system, but are very useful to many people, we are thinking of having such a similar repository.

This repository is proposed to be called jobcomm (jobcommunity on top of obcommunity and community it sounded too long) but work slightly different. The proposed functionality for now is to not provide built packages for this, just the source repository like jobcore and jobextra as found on git.disroot.org/joborun-pkg and the database files of jobcomm in osdn, so other users can see upgrades and additions easier.

This means that you will see the package recipe (PKGBUILD and remaining help files), you clone the repository and build the package yourself, as described in how to build pkgs in joborun wiki.

The pacman.conf entry for this would be:


[jobcomm]
#Server = file:///var/cache/jobcomm/
Server = https://osdn.net/projects/joborun/storage/jobextra/

and it should be placed right below the jobextra entry and above ArchLinux [testing].

Unfortunately you will have to flip between local and osdn repository every now and then to check for additions/upgrades. BUT!! Your main installation can have the osdn repository address and your buildbot [jobbot] chroot can have the local repository. So when your daily runner system sees and upgrade from osdn, you go to your jobbot, build the package, place it in /var/cache/jobcomm/ and then link the package to /var/cache/pacman/pkg/ so your installation can find it and install it.

But here there is a glitch, I can make the osdn database from the packages built on my machine, and the checksums of the database will reject yours, so either just use

sudo pacman -U /var/cache/jobcomm/pkgname-pkver-*pkg.tar.xz
or you have to be flipping /etc/pacman.conf from local to remote repository.

Generally the reason for this is that some large packages take too much space in the limited osdn server, and many of those are binary packages that makepkg just explodes in src/ and stages them in pkg/ and repacks them into a package. So basically it is time to download a set of binaries (most browsers take hours to compile so most get the binary from source which is usually is produced in debian .deb format or fedora .rpm) uncompress and explode the archive, rearrange (seconds or less), throw back into a tar archive and compress, which in turn you install by uncompressing and exploding the tar. You might as well do this on your own machine than adding a middleman, on an already risky business of downloading and installing binaries.

So recipes for brave, palemoon, waterfox-classic, etc. may be found in jobcomm, building is pretty simple and requires a few minutes.

2 #### How jobcomm can evolve ####

I am thinking of jobcomm more like an AUR repository rather than a coordinated joborun repository. Sure some initial packages will be placed there, but I expect the community to add more. Adding your maintainer's information is optional, especially a contact email so if other joborun users have an issue with the software they can contact the actual maintainer who would best be fit to answer the question. So jobcomm in git.disroot.org/joborun-pkg jobcomm will be open to registered disroot members who want to contribute.

You can open an issue on this file and discuss this here or in reddit.com/r/joborun

Alternatively you can fork jobcomm into 2 repositories, your own local repository and the one from osdn indicating of an update.


[jobcomm]
Server = https://osdn.net/projects/joborun/storage/jobextra/

[jobcomm0]
Server = file:///var/cache/jobcomm0/

The first notifies you of an upgrade the second is your local fork where you install the one you built.

% sudo pacman -S jobcomm0/palemoon

for example, whose pkgver and pkgrel match the one of jobcomm and only when you see a difference on jobcomm will you know it is time to upgrade, otherwise you are all caught up.