Some ideas/questions about yum

[Hedayat Vatankhah]

/*Seth Vidal <skvidal at fedoraproject.org>*/ wrote on ‫جمعه ۲۸ اوت ۰۹، 
۲۲:۰۳:۱۰‬:
>
>
> On Fri, 28 Aug 2009, Hedayat Vatnakhah wrote:
>
>>
>> You don't need to know about all existing repositories, since you can 
>> still resolve file level dependencies. In such
>> cases you'll be forced to download the other file I mentioned 
>> (primary_file_deps.db).
>> I don't see why you'll need to recreate all repos when one of them 
>> changes! Sorry :( And its impossible to state anything
>> about the last item.
>
> You're going to pretty much instantly download the complete filelists 
> then b/c if you add ANY 3rd party repo you're going to need /bin/sh 
> probably immediately along with various and sundry items in /etc/.
Yes, that's true if the third party repositories do not use this 
feature. BTW, I think if you make an exception for /bin/ and /etc/ 
contents, you'll still save a reasonable amount of space in the primary 
repo (I think it would be enough to remove library dependencies).

>
> Now - an argument could be made for nuking /bin/sh deps from orbit but 
> that's going to have to happen at another layer than this.
>
>> IMHO, even a single php/python script can provide such a XML RPC 
>> service (web service was just an example). Mirrors could
>> get this file just like the other files when syncing. But well, it'll 
>> be http only. The GPG sign issue could be
>> problematic, but would you really need to sign the traffic?!
>
> 1. a lot of our mirrors won't want to run any app
> 2. some of our mirrors are not running on linux (or sometimes not even 
> on a unix)
> 3. it makes 'mirroring' things much harder in the traditional sense
> 4. yes you need to sign it otherwise you'll get the same set of 
> problems we just dealt with last fall. We have to sign the metadata to 
> make sure clients aren't screwed.
OK, so, the last item is enough to reject the whole idea.

Thanks,
Hedayat

>
>
>
> -sv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090829/08e9cf0c/attachment.htm>