Debian Support

I have two comments:

First, this probably applies to the other options (architectures, distributions, etc.) as well. (It raises the larger question how much validation of user input we want to do).

The second issue is one of implementation. I think it is probably not a good idea to validate remotes right at the time of creation (It could be a plausible use case to create a remote for a upstream repository that is currently unavailable, and then to use it at a later time, and upstream repos could change). Instead, I think any validation should happen when the remote is actually used to synchronize a repository. At that point it would be nice to have clear errors explaining there is something wrong with the remote being used, rather than just creating a broken repository.

This comment is copied from the discussion on the PR:

I have been thinking about this a bit more. For reasons of both usage and implementation I do not think asking for structured user input is practical.

The only solution I can come up with to satisfy all use cases is making the behaviour configurable (globally and/or per remote). Lets say a remote could have "strict": true or "strict": false.

A strict remote would throw a hard error whenever a remote repository is missing a distribution known to the remote, or when one of the distributions is missing a component or architecture known to the remote. A non strict remote would log a warning instead.

Personally I would vote that strict remotes are the default behaviour (since I think most users should keep their pulp repos simple (for example by keeping it one distribution per repo) and would benefit from sanity checking on the remotes they create. However, that is debatable since the non strict remote is more "liberal" in what use cases and input it accepts (https://en.wikipedia.org/wiki/Robustness_principle).

Any thoughts on the general approach?

PR: https://github.com/pulp/pulp_deb/pull/293