Re: sources.list brainstorm
On Sat, Jul 2, 2011 at 17:03, Paul Wise <pabs@debian.org> wrote:
> On Sat, 2011-07-02 at 16:03 +0200, David Kalnischkies wrote:
>> We currently ship the infrastructure for a server-side automatic mirror
>> selection with the 'mirror' method. I think ubuntu wants to try to deploy
>> it (at least that is what they planed on the last uds), i lost track if debian
>> wants to play with it after Peter Palfrader did some personal tests with it.
>> See also http://lists.debian.org/debian-devel/2011/03/msg00491.html
>>
>> It's the first time that i hear something about client-side selection through,
>> so i don't know what the requirements for this would be…
>> (and more importantly: Who is willing and/or does work on it)
>
> I interpreted Peter's comments in that thread and earlier threads as
> being in favour of getting rid of GeoIP based mirrors and moving to
> something more client-side. For example:
>
> http://lists.debian.org/20100906082622.GO25990@anguilla.noreply.org
>
> I personally think client-side mirror selection is more flexible and
> interesting for users, Debian and mirror admins.
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…
>> Thats not only easier for a human being to do but also for software
>> working with it - APT is just the tip of the iceberg here as it doesn't
>> even have functionality to write these files (instead i think some
>> front-ends implement it on their own. python-apt can do it, too,
>> d-i obviously, stuff like apt-spy and and and …).
>
> Yeah, kinda scary. Backwards compatibility should be doable though.
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…
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.
>> So at best search for consents by asking all the others and at the end
>> drop a patch here which implements it. ;)
>
> I'm completely unfamiliar with apt internals and lack time so a patch is
> unlikely from me.
I didn't mean you directly, sorry. 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"…
Best regards
David Kalnischkies
Reply to: