Seth
Vidal
<skvidal@xxxxxxxxxxxxxxxxx>
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
|
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
