[Pulp-list] Handling Uploads to repos with feed

[Jeff Ortel]

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?

>
> Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5126 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20101011/a41b8c7a/attachment.p7s>