https://release-engineering.github.io/productmd/treeinfo-1.0.html

After reading this description and the productmd docs the DistributionTreeRepository makes more sense to me now. I think these statements are true:

A repository that has for example 3 distribution trees would have 3 DistributionTree units in it.
Each one of these units would be associated with another DistributionTreeRepository which is associated with a Repository that stores all the actual rpms.

Why not have the DistributionTree have the variant attributes on it and ForeignKey point to the Repository containing its content?

I think one repository can have only one DistributionTree unit (aka one [.]treeinfo file).

As for the ForeignKey vs through model - a DistributionTree can reference any number of RPM repositories and it has attributes specific to each relation. I think through model is appropriate here.

Let me know if I misunderstood any of your comments, bmbouter.

ttereshc wrote:

I think one repository can have only one DistributionTree unit (aka one [.]treeinfo file).

As for the ForeignKey vs through model - a DistributionTree can reference any number of RPM repositories and it has attributes specific to each relation. I think through model is appropriate here.

This clear is up for me thanks. I agree the through model is appropriate.

I guess my last question is, can a repository be referenced by multiple DistributionTree objects? Or at sync time is the Repository always dedicated to backing one DistributionTree?

Let me know if I misunderstood any of your comments, bmbouter.

I guess my last question is, can a repository be referenced by multiple DistributionTree objects? Or at sync time is the Repository always dedicated to backing one DistributionTree?

I think that, in theory, a repository can be referenced by multiple DistributionTree objects.
In real life, it either never happens, or it happens very rarely. At least with the Centos/Fedora repos.

The only example which comes to mind is if there was some error in the treeinfo file, and it got updated/fixed in the remote kickstart repo. In this case, when we resync, we create a new DistributionTree unit and we could point to the existing RPM repos which hasn't changed.

If it's much simpler to have the limitation that the "Repository is always dedicated to backing one DistributionTree", I think it's ok, since it's a very rare case to have RPM repos reused.