repo: handle properly nested suites

[rezib]

On Debian wheezy with reprepro 4.12.5-1, with the following info_suites:

info_suites=jessie:calibre9/debian,jessie/updates:calibre9/debian-security

The resulting layout in the mirror_root of the local disk is:

# ls jessie jessie/dists jessie/updates jessie/updates/dists
jessie:
dists  pool  project  updates

jessie/dists:
jessie  stable

jessie/updates:
dists  pool  project

jessie/updates/dists:
jessie  stable

This is an issue since when clara first sync the jessie suite, it deletes recursively the jessie/updates directory since it is not present on the source server (it is in another webroot). Then, the jessie/updates suite must be sync from scratch every times, and this is a bit annoying.

[ana]

Hi,

The info_suites variable is very fragile and it's highly dependant on
the server as stated in the example config.ini:

https://github.com/edf-hpc/clara/blob/master/example-conf/config.ini#L26

So it only work using "server" and "info_suites" as stated in the example config.ini
and if you change the server and edit info_suites, you have to be very careful
to keep it working as we see here :(

The problem with nested suited was already taken into account hardcoded
in the code:

https://github.com/edf-hpc/clara/blob/master/clara/plugins/clara_repo.py#L184

so the suite name would be properly handled by debmirror but the destination
folder isn't nested.

I think (untested) the problem mentioned is fixed by replacing:

jessie/updates:calibre9/debian-security

with:
jessie-security:calibre9/debian-security

However, we should fix the real problem here and this will need some discussion :-)

One possible solution inside clara is modify "info_suites" to instead of having
two values (TD) have three (TD) adding the destination folder. But:

• this would be still a bit fragile.
• I feel like we have reached more or less the limits of the ini config here
• it seems likely that we'll need to be able to sync different suites from
  different servers in the very close future ( see the discussion mentioned in ticket New feature to grab the last jenkins build and add it to repo #57)

Another possible solution is to declare all this data in a YAML file
containing the server, the suites to mirror, the destination folder, the archs
to mirror, the method, etc.

[roastercode]

Hi,

repos.ini is a mix of wheezy and jessie this ticket is old and at this time stretch did not exist.

I can fix easily the part as explain by @ana , but:

Do you want me to change it to use stretch and by the way bring Clara to last Debian 9 version codename?

Also, calibre9 is the old codename of Scibian.

Do you wish to use that codename repository or change to the last one (if the repositories with that codenames exist)?