On Sat, 2011-07-02 at 16:03 +0200, David Kalnischkies wrote: > From my point of view, if we really need a different format, it should be > a rfc822 one as we have a parser for that already. JSON, INI or XML isn't > exactly something you want to use if you need to write a parser for it, too, > to avoid depending on to much stuff… Yeah, I figured so. > 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. By doing it mostly on the client, I think we are more likely to have our derivatives using a similar setup. In any case, factoring the all mirror domains out of sources.list and the possibility of automatic mirror switching and choosing will be a big win over what we have now. With a client-side mirror list we can also deal with the outdated mirror situation more gracefully; automatically monitor all mirrors and drop the mirrors that are very out of date. Often there is client-only information that apt could use to make decisions about which mirror(s) to use. For example, in some parts of the world on some ISPs there are small bandwidth quotas and the ISP or one of ISP peering points has a Debian mirror that doesn't count towards that quota. A server-side solution here would not know this and could point at the wrong mirror. By knowing the whole mirror list, the client could also pull from multiple mirrors at once (kinda like apt-p2p/debtorrent but download only). I talked to a mirror admin in Thailand at a MiniDebConf and due to network restrictions (per-connection bandwidth limits IIRC) they had developed a way to pull from multiple mirrors at once so they could keep their mirror up to date properly. It is possible that there are users on these sorts of connections too. > The only obvious advantage of a single line is that it can be > disabled by commenting out a single line. Also, it's likely that > i want to comment out a release from time to time (if i am not pin-savvy) > instead of wanting to comment out contrib or non-free. Personally I think the advantages of another format outweigh this. > 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. > These are all not a reason for not changing it, but it should be considered > that the single line isn't a completely none-sense choice from a decade ago > and a lot of people and software are somehow used to it… It is indeed very entrenched. > 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 also looked at how YUM does it, some interesting options there: > > > > http://www.centos.org/docs/5/html/yum/sn-yum-maintenance.html > > If i understand this right, they even have a new stanza for each component, > not only for a release… ;) Yeah. Mainly the options were interesting. > You have already found the []-optionfield which is the recycled as never used > []-vendorfield, which we have already some requests to enable some more > options. Clearly, if we go for a stanza instead, this would be a bit saner… Interesting, I didn't know about the vendor thing. > Just for the record: apt-rpm already exists and is used by some distros, > (in different versions for different rpms to make it even harder to track) > it's just that the fork happened at 0.5.something (thats before apt-security) > and is even more maintainance-only than our lovely apt here, so a merge > back is even through some features are interesting not very likely to happen > in the short- and middleterm making it even more unrealistic in the longterm. > (I would be happy if someone could prove me wrong through…) Ok. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part