[SOLVED] pacman download and install later

adervisevic · 2024-10-14 13:14:28

Hello,

I'm a bit confused, about the pacman flags.

What I need is:

1. Download packages (and their deps.??)
2. If the download is successful, run some bash script
3. If the bash script is successful, install the packages from step 1.

Currently, for the above steps I'm using (in my update.sh)

sudo pacman -Syuw --noconfirm --needed - < "packages.txt" &&
sudo ./something.sh &&
sudo pacman -Syu --noconfirm --needed

I'm totally unsure if that's the correct syntax and way to do it. Please help and advise.

Last edited by adervisevic (2024-10-14 16:50:34)

Scimmia · 2024-10-14 13:20:13

Are you updating or installing a list of packages? I don't understand why you would have -Syu as well as packages.txt.

Trilby · 2024-10-14 13:25:02

You should not have the "y" flag in the second call to pacman. In practice this is highly unlikely to matter as the odds of a change in the repos between your first and third command is (most likely) quite slim. But on the off chance their is a change the "y" flag in the second pacman command will only serve to break the assumptions of your set up. It will never serve a useful purpose. There's also no need for "--needed" (kinda' ironic) in the second pacman command, and depending on your response to Scimmia's question it may not even be relevant for the first.

I'm also curious what your script is intended to do - I can't help but suspect that this is hiding an X-Y question.

Last edited by Trilby (2024-10-14 13:26:13)

adervisevic · 2024-10-14 13:55:42

It's all part of an update.sh script I'm writing. The packages are installed, but sometimes I'd need to install new ones (and their dependencies) as listed in packages.txt (which I might casually update with new packages)
what I needed to achieve is to: "do something (call/execute a bash script)" after the packages are downloaded, but before the install takes place.

Regarding the "XY-Problem" you might be right: perhaps I overthinked my problem... All I could have done is eventually is this simpler:

```sh
# update.sh
sudo pacman --needed --noconfirm -Syu - < "packages.txt" &&
./something.sh # do something if: pacman downloaded AND installed correctly
```
?

Also, (not well documented in pacman man pages) is the "--needed" flag a good idea in order to speed up the update process and make sure new packages are installed but also the existing ones are updated correctly with all their dependencies?)

(I will take time to rethink the problem I'm facing, in the meantime, what would be the best syntax, flags to the three steps? If there's one?)

cryptearth · 2024-10-14 14:04:54

adervisevic wrote:

do something (call/execute a bash script)" after the packages are downloaded, but before the install takes place.

Why? what happens in your script? Updating the system should be an atomic process without anything interfering with it

Trilby · 2024-10-14 14:09:06

Ugh ... what is something.sh?!

adervisevic · 2024-10-14 14:12:39

cryptearth wrote:

adervisevic wrote:
do something (call/execute a bash script)" after the packages are downloaded, but before the install takes place.
Why? what happens in your script? Updating the system should be an atomic process without anything interfering with it

Thank you! Okay, I'm rewriting my script to trigger/execute only after `pacman -Syu --needed - < "packages.txt"` is done without errors.

One question, that still bothers me is, if --nedded is helpful (or not reccomended?) to speed up the update process - but still update the packages to the newest versions - the ones that need to be updated?
I cannot make sense of the man page: to quote:
"--needed: Do not reinstall the targets that are already up-to-date"

Scimmia · 2024-10-14 14:13:02

You know unattended updates will end up destroying your system sooner or later, right?

adervisevic · 2024-10-14 14:30:11

Scimmia wrote:

You know unattended updates will end up destroying your system sooner or later, right?

Are you referring to the `--noconfirm` flag? I didn't know I guess how destructive an update might be?!

How would you go in that case to update a kiosk software?

What I'm currently using is:

# pacman -Syu --noconfirm --needed - < "packages.txt"
# unzip project files and run npm install
# reboot

For the update I was thinking of running an update.sh (which is tested locally on similar machines) and than perform .update.sh on the kiosk machines which should do:

# get the project zip files
# pacman -Syu --noconfirm --needed - < "packages.txt" # UPDATE PACKAGES OR INSTALL NEW ONES
# reboot

?
Thanks for any insight

Scimmia · 2024-10-14 14:33:43

Using, and updating, Arch for kiosk machines is simply insane. When you update, you MUST read what pacman tells you. If you ignore it, things WILL stop working at some point.

adervisevic · 2024-10-14 14:37:01

Scimmia wrote:

Using, and updating, Arch for kiosk machines is simply insane. When you update, you MUST read what pacman tells you. If you ignore it, things WILL stop working at some point.

Can you elaborate why would it be insane?

Why should I not use arch linux for kiosk?

seth · 2024-10-14 14:47:33

https://archlinux.org/news/

Trilby wrote:

Ugh ... what is something.sh?!

It'll make some assumptions and "assume" always just makes an ass out of u and me.
You apparently felt the need to do something™ beyond "pacman -Syu foo" and that "something" explains why it's really not a good idea to just let pacman update/install stuff and not looking at it.
Arch isn't that kind of system - some debian stable w/ minimal security patches and integration tests will reasonably allow you to do that until the next point release.

roxon · 2024-10-14 15:11:50

seth wrote:

https://archlinux.org/news/
Trilby wrote:
Ugh ... what is something.sh?!
It'll make some assumptions and "assume" always just makes an ass out of u and me.
You apparently felt the need to do something™ beyond "pacman -Syu foo" and that "something" explains why it's really not a good idea to just let pacman update/install stuff and not looking at it.
Arch isn't that kind of system - some debian stable w/ minimal security patches and integration tests will reasonably allow you to do that until the next point release.

Since on ArchLinux updates are manual by default,
is it safe to assume that if an update was a "pass" in an in-house testing environment (on a same kiosk MiniPC) to assume that that update could be *safely* triggered to the kiosk MiniPCs' in production in the same time-period?

seth · 2024-10-14 15:19:25

If you've a testing an a production system that are exact clones you can of course process the update on the testing system and then replicate it on all equal production systems, automatizing the necessary intervention.
The simgle flaw in your assumption would be "the same time-period": it has to be to the exact same state and I'd utilize a local mirror to pin that (otherwise it'd depend on the delay between the test and the rollout - which can be considerable - and the status of the, in doubt randomly, involved mirrrors)
Running "pacman -Syu" on the testing system and then, if that worked, 15 minutes later on the production systems will otherwise not replicate the testing system and you cannot predict the outcome at all (at which point Murphy's law applies)

roxon · 2024-10-14 15:32:46

seth wrote:

If you've a testing an a production system that are exact clones you can of course process the update on the testing system and then replicate it on all equal production systems, automatizing the necessary intervention.
The simgle flaw in your assumption would be "the same time-period": it has to be to the exact same state and I'd utilize a local mirror to pin that (otherwise it'd depend on the delay between the test and the rollout - which can be considerable - and the status of the, in doubt randomly, involved mirrrors)
Running "pacman -Syu" on the testing system and then, if that worked, 15 minutes later on the production systems will otherwise not replicate the testing system and you cannot predict the outcome at all (at which point Murphy's law applies)

Exactly what I thought, 1ms difference would make that assumption wrong by design
(Learning ArchLinux here) is there a way to i.e: store a list "pkg.txt" of the exact versions that "worked", and then install those exact semver'red packages? Or this (as well) is not in the spirit of ArchLinux? Or not all developers put versions to archive? (Or something else at stake I'm clearly missing?)

Last edited by roxon (2024-10-14 15:38:26)

Trilby · 2024-10-14 15:40:23

roxon wrote:

is there a way to i.e: store a list "pkg.txt" of the exact versions that "worked", and then install those exact semver'red packages?

Use a shared cache, download a set of packages you want to install / ugprade, and install from that cache on each machine.

@OP, I ask again, what is "something.sh"? What is in that script? What does it do? This information is important for us to be able to give better answers.

Last edited by Trilby (2024-10-14 16:23:42)

seth · 2024-10-14 15:51:46

Afaict roxon isn't the OP.

cryptearth · 2024-10-14 16:23:20

adervisevic wrote:

How would you go in that case to update a kiosk software?

not use Arch for such but something really tested and stable like a Debian LTS
that's not to say kiosk-system are not possible with Arch but require a whole lot more attention than just replicate a test-system once a month
kiosk-systems by definition should be designed in a way with high resistance to local manipulation in mind - if ypu just blindly update and reboot and some point you will end up with an open rescue shell in some remote location - a possible way for an attacker to get into your systems
for such situations you want to have some sort of remote killswitch in place like a remote operated power switch or a kvm with which you can monitor the proper boot after an update
ocerall depending on how many systems we talk about and how far they are from the next trusted fiel technician it might be more reasonable to prepare a working image once a month or after some critical update and have someone drive around with a thumbdrive and update the systems manual local on site

overall it's a neat question for training or students - but in reality you need a bullet proof setup depending on what you deal with

adervisevic · 2024-10-14 16:50:11

Trilby wrote:

roxon wrote:
is there a way to i.e: store a list "pkg.txt" of the exact versions that "worked", and then install those exact semver'red packages?
Use a shared cache, download a set of packages you want to install / ugprade, and install from that cache on each machine.
@OP, I ask again, what is "something.sh"? What is in that script? What does it do? This information is important for us to be able to give better answers.

Ok, thanks, will wait for everything to download and install, and finally trigger some sripts.

Last edited by adervisevic (2024-10-14 16:59:06)

Arch Linux

#1 2024-10-14 13:14:28

[SOLVED] pacman download and install later

#2 2024-10-14 13:20:13

Re: [SOLVED] pacman download and install later

#3 2024-10-14 13:25:02

Re: [SOLVED] pacman download and install later

#4 2024-10-14 13:55:42

Re: [SOLVED] pacman download and install later

#5 2024-10-14 14:04:54

Re: [SOLVED] pacman download and install later

#6 2024-10-14 14:09:06

Re: [SOLVED] pacman download and install later

#7 2024-10-14 14:12:39

Re: [SOLVED] pacman download and install later

#8 2024-10-14 14:13:02

Re: [SOLVED] pacman download and install later

#9 2024-10-14 14:30:11

Re: [SOLVED] pacman download and install later

#10 2024-10-14 14:33:43

Re: [SOLVED] pacman download and install later

#11 2024-10-14 14:37:01

Re: [SOLVED] pacman download and install later

#12 2024-10-14 14:47:33

Re: [SOLVED] pacman download and install later

#13 2024-10-14 15:11:50

Re: [SOLVED] pacman download and install later

#14 2024-10-14 15:19:25

Re: [SOLVED] pacman download and install later

#15 2024-10-14 15:32:46

Re: [SOLVED] pacman download and install later

#16 2024-10-14 15:40:23

Re: [SOLVED] pacman download and install later

#17 2024-10-14 15:51:46

Re: [SOLVED] pacman download and install later

#18 2024-10-14 16:23:20

Re: [SOLVED] pacman download and install later

#19 2024-10-14 16:50:11

Re: [SOLVED] pacman download and install later

Board footer