On 10/11/2010 12:22 PM, Mike McCune wrote:
On 10/11/2010 10:20 AM, Jeff Ortel wrote:On 10/11/2010 10:17 AM, Pradeep Kilambi wrote:Should we allow the case where, user creates a repo with a feed, syncs down the content and then tries to upload additional content to the same repo? Pros: * A user probably will have an easy time adding custom content to their repos without having to create new repos Cons: * We need to regenerate metadata for the repo. Today we get the metadata for repos with feed directly from the feed. * Will need to worry about what version of RHEL/Fedora pulp is running on for compatible yum metadata. * For Red Hat repos, we probably dont want to allow this anyway. So we'll need some extra rules to bypass this. Overall seems like keeping uploads separate from feed repos is cleaner. User can always create a new repo, upload content and subscribe to both repos to get that additional content.Agreed, we should keep them separate. Also, we discussed (in imanage) supporting repos which extend other repos. If we still intend to do this, then users can easily create a repo with no feed that extends a repo that does have a feed. This mitigates the need to subscribe to both repos.I still don't see why it is all that different than what we have now with the addition of the need to run createrepo --update after a sync like we do now after a package upload ... Is there something more than that?
For me, preventing uploads to repos with feeds has nothing to do with the overhead of running 'createrepo --update' but instead has to do with preserving the integrity of repos with feeds. I think there is some expectation that repos with feeds are exactly synchronized with the feed (repo). Perhaps, my perspective of what the /feed/ represents is incorrect?
Description: S/MIME Cryptographic Signature