Removal of the base repository

[poncovka]

The concept of the base repo

The Anaconda's package installation support is based on a concept of a base repository. It means that one repository is the main one and any other repositories are additional. However, DNF treats all repositories the same way, so this concept doesn't really make sense and only complicates things. Our plan is to drop it and support just a list of repositories. We would like to start with changing the backend, but we need to extend the kickstart support first.

Current kickstart commands

The base repository can be defined by one of the following kickstart commands. We can keep the compatibility with these commands, but we won't be able to generate them in the output kickstart file. It won't be possible to decide whether a repository should be generated as the repo kickstart command or, for example, the url kickstart command. These commands could be eventually deprecated and removed.

cdrom
hmc
nfs
harddrive
url

The additional repositories can be defined by the repo kickstart commands. We would like to extend this command, so it can be used to define any of the base repo sources mentioned above.

Changes in the repo command

We would like to suggest the following changes in the repo kickstart command.

The --name option

At this moment, the repo name is mandatory for additional repositories. We would like to make it optional and generate a predictable unique repo name if none is provided. For example, anaconda-1. This change is not required, but it could improve the usability of the command and make the kickstart files easier to write and read.

The --source option

The --source option would specify the type of the source that provides this repository. For example, cdrom, hmc, nfs, hdd and url. By default, the source should be url. However, if the --baseurl option is set to a path that starts with nfs://, the source type should default to nfs to keep the compatibility with the current support. This use case should be deprecated and eventually dropped.

The nfs options

The repo --source=nfs command should support the following new options. The hostname and directory are mandatory:

--nfs-server <hostname>
--nfs-dir <directory>
--nfs-opts <options>

The hdd options

The repo --source=hdd command should support the following new options. Both options are mandatory:

--hdd-partition <partition>
--hdd-dir <directory>

The url options

Only the repo and repo --source=url commands should support the following existing options:

--baseurl <url>
--metalink <url>
--mirrorlist <url>

However, see the exception for repo --baseurl=nfs:// above.

[poncovka]

@bcl, @jstodola, @jkonecny12, what do you think about this proposal?

[jkonecny12]

Seems good to me. I'm just thinking how we will solve command line parameters like inst.repo=nfs://... and inst.addrepo=TEST,nfs://...?

Another question is inst.addrepo=TEST,file://...?

[poncovka]

Seems good to me. I'm just thinking how we will solve command line parameters like inst.repo=nfs://... and inst.addrepo=TEST,nfs://...?

We will be able to keep the compatibility with these cmdline options. Later, we could try to drop the support for inst.addrepo and support only multiple inst.repo commands, but that's out of the scope of this discussion.

Another question is inst.addrepo=TEST,file://...?

This is the url source type.

[jkonecny12]

However, if the --baseurl option is set to a path that starts with nfs://, it should be nfs to keep the compatibility with the current support. This use case should be deprecated and eventually dropped.

Does that mean that we will change the source in the output kickstart or that the user is required to set the source in kickstart. I guess that you mean the first but I want to be clear about that.

[poncovka]

We cannot require the --source option, because it would break the current use cases. However, pykickstart can detect this cases and set up the new options automatically.

[jstodola]

IMO, it still makes sense to have one repository as the main one - maybe it's even necessary?
If you had several repo kickstart commands in the kickstart file, how would the installer know which one to use for fetching the stage2 image? The first repo command in the kickstart? Go through all defined repositories and use the first one with existing stage2 image?

One note - when using the repo kickstart command for cdrom/hmc/nfs-iso/hdd-iso/ sources: these sources could mean that multiple rpm repositories are present in the specified location - like in case of RHEL with BaseOS and AppStream repositories on DVD.iso.

[VladimirSlavik]

I agree that this says nothing about stage2. That should be untangled from repo, I think.

[jkonecny12]

IMO, it still makes sense to have one repository as the main one - maybe it's even necessary? If you had several repo kickstart commands in the kickstart file, how would the installer know which one to use for fetching the stage2 image? The first repo command in the kickstart? Go through all defined repositories and use the first one with existing stage2 image?

@VladimirSlavik :
I agree that this says nothing about stage2. That should be untangled from repo, I think.

I don't think we want to add new command to the kickstart file just to download stage2. In general, I don't like this functionality and I would not like to make it more obvious. However, we could add some parameter exactly for this, maybe something like --primary or --base to give Anaconda a note that this could be used to download stage2. It could be even improvement to the current state because than you could have multiple repo commands with this which would have the parameter and they would be tried in order to find the stage2 image.

One note - when using the repo kickstart command for cdrom/hmc/nfs-iso/hdd-iso/ sources: these sources could mean that multiple rpm repositories are present in the specified location - like in case of RHEL with BaseOS and AppStream repositories on DVD.iso.

No problem with that. Right now the BaseOS and AppStream are loaded from a .treeinfo file which is a root of the repository. That would still apply and we would load multiple repositories by one repo command. I would say that it would be even less confusing and more robust than what we have now but that may be just my feeling.

[bcl]

My first question is why? What's broken that this is fixing? I'm also generally reluctant to continue the explosion of command arguments for every possible combination of things. I'd rather see repo be able to use the the URI to determine the source type instead of adding a new option.

I'd have to dig into the anaconda code again to be sure, but I'm fairly sure that while dnf treats all the repos the same, anaconda needs to have one 'main' repo where it gets things like stage2, .treeinfo, updates.img, product.img, etc. so that would be the first thing to look out for.

I think repo --name=foo is important. The problem with automatically generating the names is it then becomes harder to debug problems because you have to figure out what repo the random name was assigned to. It isn't a big burden to ask users to name their repos, especially since they already have been. Another consideration is that repo --name=updates without anything else enables the updates repo on the installer image (or at least it used to). So there are other uses for it.

I really don't want to start adding new nfs options to repo. We already have documented ways to parse nfs: URIs to get all of that information.

[jkonecny12]

Great arguments indeed, thanks for your input.

About the main question here, I see this as an improvement. Why to bother people about thinking what should be the primary repository. For most users is just something annoying they have to learn/do. So removing this responsibility from them seems like a benefit.

For the more parameters to the repo command, I see it in a similar way as you. However, if we want to drop the main/additional repository solution then you should go with hdd,url,liveimg commands or with repo and going with the first variant will add a lot of duplicate code.