Install addons offline

Greetings,
I see that from here you can download the addons packages for the 2.27 version of IpFire:

https://mirror1.ipfire.org/pakfire2/2.27-x86_64/

Once the .ipfire package has been downloaded from the browser and uploaded to an IpFire folder, is it possible to install it on the machine in offline mode?
How can it be done?

Thank you in advance.

There is no value in downloading packages directly.

If you want to install from command line then:

  1. identify the package name, via Pakfire in WUI - if you donā€™t already know it
  2. from root login, run ā€œpakfire install <package name>ā€
1 Like

Your link is just one of a couple of mirrors.
The installer software pakfire just tries to select one of these. This distributes the load of these servers in a (hopefully) fair process. On the other hand not all servers are accessible from all places with the same quality.

The process

  • select a mirror
  • download the package from there
  • check validity of the download
  • install on the local system

is controlled by the pakfire program, which is an essential part of the IPFire system.
It may be changed by the devs, when approbriate. This is true for the database used also.
Therefore a recipe extracted from the coding of the pakfire program isnā€™t really preferable. It may become invalid. The standard way is under control of the development community, which does reviews of changes also.

BTW: Why do you want to do this process ā€˜offlineā€™?

1 Like

I thank you for the answer. You are right about the command line installation. ā€œpakfire install ā€˜package nameā€™ā€ works.
However, I have found that the .pakfire package is still downloaded and the installation does not work if IpFire is offline.
But I too fear that there is no other solution.
My idea was to keep the packages and old versions of IpFire, for future experiments, in case they are no longer available on the servers.

Old CUs are available a long time.
About the old versions of addons it is a bit more ā€˜trickyā€™. But pakfire usually tries to serve you with a functioning CU / addon combination.

BTW: Why do you want to do this process ā€˜offlineā€™?

Yes, I understand the question. As already mentioned to Rodney Peters, my idea was to keep the old packages and old versions of IpFire, for future experiments, in case they are no longer available on the servers. Itā€™s a ā€œgenericā€ system that I use a bit with all free software. This often helps me recreate old situations, get old programs to workā€¦ things that are impossible in updated software. For example, I see arm32 will be abandoned. For me it would be interesting to keep the latest version of IpFire arm32 and be able to always install the old packages, without the fear that tomorrow they will no longer be available. This was the dominant motif.

I see.
But IPfire is an evolving system. Its main purpose is to establish a secure internet connection. Because no software is error free, evolution takes place in security aspects.
Your example ā€˜arm32ā€™ just shows such an aspect. Many security patches are applied to the kernel and/or essential software packages. If an architecture isnā€™t supported by the maintainers any more, it is great effort to hold them up-to-date. Therefore such systems can be abondend by the devs, especially if there isnā€™t a ā€˜standard BSPā€™ like with x86 systems ( BIOS, UEFI, ā€¦ ).
It makes no sense to maintain a potentially unsecure system, IMO.
The IPFire community tries to maintain a system containing the actual versions of the functional parts. There are few cases demanding a roll back to a previous version. Most such problems are found during the testing phase by ā€˜trial and errorā€™ and/or the development process by code review.

2 Likes

Yes. I totally agree with that.
I am fond of old technologies and old software and I like to collect everything, but I realize that in the case of IpFire (internet security) things are delicate and therefore I understand there is no point in keeping old packages and old versions in this case.

1 Like