Download the Debian/Ubuntu repository signature with wget, not curl

[SunBlack]

When I set up a new Ubuntu container and install Jenkins, the installation instructions so far don't work directly because you still have to install curl (in addition to Java), which is unnecessary since wget is already pre-installed. So the command is now similar to the Fedora script.

[gounthar]

Hi @SunBlack, and thanks a lot for your first contribution. 🤗

I'm in the middle of the bridge here. Most of the Jenkins scripts (in the infra, packaging, ...) heavily rely on the curl command. You're correct that curl doesn't come preinstalled with Debian/Ubuntu, but wget does. However, we can assume that most of our end-users already have curl installed, as many scripts from other projects (such as the Docker installation) also make extensive use of curl.

So, it wouldn't hurt to use wget instead of curl, but we could also keep curl and add a message saying, "You should have curl installed; it's a prerequisite." Using a wget command, though, aims for simplicity. 🤔

[SunBlack]

I'm in the middle of the bridge here. Most of the Jenkins scripts (in the infra, packaging, ...) heavily rely on the curl command. You're correct that curl doesn't come preinstalled with Debian/Ubuntu, but wget does. However, we can assume that most of our end-users already have curl installed, as many scripts from other projects (such as the Docker installation) also make extensive use of curl.

Indeed, many are using curl, although I'm not quite sure why (probably out of habit, since it can handle more protocols, even if it's not needed here). On a system where you already have other things installed (like Docker) curl is mostly present, true. But if you don't look at the Docker host, but at a Docker container, it's mostly not there yet (didn't tested it now, whether, e.g., the official Docker image ubuntu::22.04 has it preistalled).

So, it wouldn't hurt to use wget instead of curl, but we could also keep curl and add a message saying, "You should have curl installed; it's a prerequisite." Using a wget command, though, aims for simplicity. 🤔

I would still be in favor of taking wget here. If you prefer to use curl, you can adjust the line briefly yourself, but since wget is preinstalled, using curl adds extra work as you cannot bundle all apt install targets in one call (you need to install first curl, then adding the keyrings and than another install step).

Btw: We could also switch from apt-get to apt in the documentation, since this seems to be the preferred choice by now.

[colmcd]

This is Not the way to proceed.

Several points:
You will break all installations that have "curl" installed but not "wget". My setup is like this at the moment.
Curl allows for a stack of feature flags that wget does not. So if i need to set proxies, adjust the command, etc I can via system aliases.
The behaviour under the hood is very different. You are changing a stack of builds due to distro issues.

It is trivially easy for the Ubuntu Jenkins package maintainers to add Curl as a dependency on the Jenkins apt package. Ubuntu should make this change, not jenkins

The only way through I can think of is a system setting/switch which allows for Curl/Wget to be selected i.e. if switch=0 curl, =1 wget =2?? and for the codebase to be refractored to support that selection.

Otherwise please reject this change. You are breaking a lot of working systems.

[zbynek]

It is trivially easy for the Ubuntu Jenkins package maintainers to add Curl as a dependency on the Jenkins apt package

Not related to this issue. The question here is what is the best tool for downloading repository keys before Jenkins is installed.

You are breaking a lot of working systems.

Since this is just a documentation change, it's not really breaking anything.

[SunBlack]

Several points: You will break all installations that have "curl" installed but not "wget". My setup is like this at the moment.
...
Otherwise please reject this change. You are breaking a lot of working systems.

How a one-time command breaks any working system? 🤔 And if you search for it, you will only find the information that the wget package is preinstalled on most Linux distributions today. From there I ask myself also here: How is it that it is not present on your system, if you ignore the option of manual uninstallation, which is probably not the case for a typical system?

Curl allows for a stack of feature flags that wget does not. So if i need to set proxies, adjust the command, etc I can via system aliases. The behaviour under the hood is very different. You are changing a stack of builds due to distro issues.

It is trivially easy for the Ubuntu Jenkins package maintainers to add Curl as a dependency on the Jenkins apt package. Ubuntu should make this change, not jenkins

I wouldn't call it distro-issue if the manual is explicitly for Debian/Ubuntu and the maintainers of it decided to pre-install wget and not curl. What other distros have as default is not relevant for this PR, as it is only about the Debian/Ubuntu instructions.

It is true that curl is more powerful, as already written as well. But if someone needs e.g. additional settings, I assume that the person is also able to rewrite/adjust a command for himself. However, we are talking about the default case here: wget is pre-installed on Debian/Ubuntu, curl is not and most systems will not need special settings do download sth. (btw: wget does support proxies, otherwise the option --no-proxy would make no sense).

Unfortunately, Asciidocs does not seem to support tabs by default, otherwise the discussion would be superfluous, as we could simply include both variants in the documentation without it becoming bloated.

[MarkEWaite]

@SunBlack will you also propose the same change in the packaging repository so that users see the same instructions when they open https://pkg.jenkins.io/debian/ and https://pkg.jenkins.io/debian-stable/ ?

I think this is a reasonable change and am willing to approve and merge it when the pull request is ready for the packaging repository. Eventually we hope to have the packaging pages redirect to the www.jenkins.io installation pages, but we're not ready for that yet.