On Sat, 2011-07-02 at 20:40 +0200, David Kalnischkies wrote: > I know exactly nothing about mirror business, but from my naïve viewpoint > these two aren't utterly different. 'mirror' method gets currently a list > of mirrors from the specified source and tries one, if that fails tries the > next and the next and … > Ubuntu want to deploy mirrorbrain on the server-side as some things > really seem to be better decided by the servers (e.g. load balancing). > I don't see why a "clientbrain" couldn't be added "on the other side". > But yeah, different topic and i am certainly not the right one for this talk… Hmm, mirrorbrain looks pretty interesting. > Yeah sure, but if user A can't enable non-free with $whatever because > $whatever doesn't support this new format yet the user is either annoyed or > d-i doesn't implement it as long as a lot of $whatever's have implemented it. > But why should $whatever implement it if nobody uses it anyway… Yeah, bootstrapping any format transition is pretty hard. > dpkg is still struggling to teach other programs that his info-files are a > no-go and these are "only" internal files nobody should read/write anyway… > And on this depends MultiArch, not an alternative format for sources.list, > so i fear even higher resistance if not everybody said 'yes, great!' before > and also meant it. Ouch :( > I didn't mean you directly, sorry. Ah, I wasn't quite sure if you did mean me. > I just said it to avoid that anyone gets the impression i would jump > on that train now as a driver or something. If we have a (frozen) > spec, why not, if nobody else want to do the patch before i am fine > with doing it, but until then i treat it the same way as i should have > treated e.g. "Removing long descriptions from Packages"… Ok, makes sense. On the moving long descriptions from packages thing, What is the status of that? I run Debian on my phone (OpenMoko) and stripping the descriptions would reduce the time it takes to decompress the packages file and apt-get update in general. On that note I would really encourage more splitting of the Packages and Sources files. I would do it based on purpose; low level stuff needed by dpkg/apt for dependency resolution etc, stuff needed by users (homepage, description etc) and other stuff. That would also allow to merge the upstream metadata stuff into debian/control but not have it shipped in the Packages/Sources files: http://wiki.debian.org/UpstreamMetadata -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part