__package_apt to accept .dpk files directly #340

fancsali · 2022-07-14T19:35:29Z

fancsali commented

2022-07-14 19:35:29 +00:00

Background

To install software that is either custom or not yet available in any official repos, one would go do something like this:

As having a compiler on a production machine has some security implications, the software would be built as a .dpkg package
Then uploaded and installed it with __package_dpkg.

But this would not take care of the dependencies, so one would either need to install every dependency "by hand" or perhaps run apt-get install --fix-missing to make sure things work out.

However, a perhaps less well-known feautre of apt is that it'd happily accept a package in a file and install that, satisfying the dependencies through the normal sources and repos. Unfortunately this is not exposed via __package_apt at the moment.

Solution approach

As both __package_apt and __package_dpkg are wrappers there are two obvious ways to make this more convenient:

Either Update __package_dpkg to run apt-get install --fix-missing after installing a package;
or extend __package_apt with the capability to accept package files.

As the first one seems to be somewhat of a hack and would also introduce a new dependency on apt into __package_dpkg (if a machine has apt it is guaranteed to have dpkg as well - but the reverse is not necessarily true), the second one seems to be favourable.

This change exposes that already present functionality of apt to the users of cdist.

NOTE: This PR would also seem to essentially deprecate __package_dpkg, but that's not the intent here: for completeness sake, for sake of backwards compatiblity and to keep allowing users full control I'd definitely keep that around too.

# Background To install software that is either custom or not yet available in any official repos, one would go do something like this: * As having a compiler on a production machine has some security implications, the software would be built as a `.dpkg` package * Then uploaded and installed it with `__package_dpkg`. But this would **not** take care of the **dependencies**, so one would either need to install every dependency "by hand" or perhaps run `apt-get install --fix-missing` to make sure things work out. However, a perhaps less well-known feautre of `apt` is that it'd happily accept a package in a file and install that, satisfying the dependencies through the normal sources and repos. Unfortunately this is not exposed via `__package_apt` at the moment. # Solution approach As both `__package_apt` and `__package_dpkg` are wrappers there are two obvious ways to make this more convenient: * Either Update `__package_dpkg` to run `apt-get install --fix-missing` after installing a package; * or extend `__package_apt` with the capability to accept package files. As the first one seems to be somewhat of a hack and would also introduce a new dependency on `apt` into `__package_dpkg` (if a machine has `apt` it is guaranteed to have `dpkg` as well - but the reverse is not necessarily true), the second one seems to be favourable. This change exposes that already present functionality of apt to the users of `cdist`. **NOTE**: This PR would also seem to essentially deprecate `__package_dpkg`, but that's not the intent here: for completeness sake, for sake of backwards compatiblity and to keep allowing users full control I'd definitely keep that around too.

fancsali added 1 commit 2022-07-14 19:35:31 +00:00

35582f948f __package_apt to accept .dpk file as --source

fancsali changed title from ~~WIP: __package_apt to accept .dpk files directly~~ to __package_apt to accept .dpk files directly

2022-07-14 22:16:21 +00:00

nico reviewed 2022-07-29 08:59:22 +00:00

cdist/conf/type/__package_apt/gencode-remote

					
				@ -106,0 +114,4 @@

				            fi

				            $__remote_copy "$source_path" "${my_target_host}:$tempfile"

				            echo "$aptget $recommendsparam install $tempfile"

nico commented

2022-07-29 08:59:22 +00:00

Interesting. And how is the tempfile removed eventually?

fancsali commented

2022-08-03 08:46:27 +00:00

Well, I reckon, the OS will remove it eventually; wouldn't it?

nico commented

2022-08-03 09:04:46 +00:00

No, why would it? It's a file we copied and in case we use this type a lot, we will have a lot of leftovers. I don't think this is a clean implementation, TBH.

fancsali commented

2022-09-05 18:36:36 +00:00

Well, according to the FHS, it sortof does: "Programs must not assume that any files or directories in /tmp are preserved between invocations of the program." (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#tmpTemporaryFiles)

Of course, the ones stored in /var/tmp are removed less frequently, as per "5.15. /var/tmp : Temporary files preserved between system reboots" (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#vartmpTemporaryFilesPreservedBetwee).

I do recall, there was lots of debate around how cdist should clean up after itself, but I can't remember the outcome of that discussion - if it's been decided that this is the official policy now, I am happy to add that. It's just, looking at the other types, it didn't seem so...

Well, according to the FHS, it sortof does: "Programs must not assume that any files or directories in /tmp are preserved between invocations of the program." (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#tmpTemporaryFiles) Of course, the ones stored in `/var/tmp` are removed less frequently, as per "5.15. /var/tmp : Temporary files preserved between system reboots" (https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#vartmpTemporaryFilesPreservedBetwee). I do recall, there was lots of debate around how `cdist` should clean up after itself, but I can't remember the outcome of that discussion - if it's been decided that this is the official policy now, I am happy to add that. It's just, looking at the other types, it didn't seem so...

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

You can also view command line instructions.