On Sun, 2009-12-13 at 14:33 -0700, Brendan Long wrote: > On Sun, 2009-12-13 at 12:07 +0100, Jeroen Op 't Eynde wrote: > > On 12/13/2009 10:02 AM, Nathan Wayde wrote: > > > On 13/12/09 08:48, Ng Oon-Ee wrote: > > >> On Sun, 2009-12-13 at 03:31 -0500, Qadri wrote: > > >>> > > >>> So should it be a function of the program to make sure that happens? > > >>> Or is a > > >>> responsibility of the user? Should the functionality be programmed into > > >>> pacman to make sure that happens, or should we be asking that users > > >>> be aware > > >>> of what repos they're using? > > >> > > >> Well said, I agree. I believe that if separate db and package downloads > > >> are implemented it should not be so users can be 'up-to-the-minute' in > > >> packages, but for greater security. > > >> > > >> In fact, now that I think about it, having two dbs (one on the mirror > > >> with all packages as available on that mirror and one 'master' with a > > >> list of authoritative checksums) would make sense, as it fulfils the > > >> security aspect well while avoiding the problem of db/package mismatch. > > >> The 'master' db would have to have a history of previous checksums as > > >> well. > > >> > > >> > > > One possible alternative to explicitly storing a history of checksums is > > > to checksum the dbfile, and name it as such. instead of core.db.tar.gz, > > > you'd have have core.[checksum].db.tar.gz and these would be stored for > > > some time on the master. In order to make it secure the standard > > > checksums would have to be upgraded to something with less collisions > > > than md5. > > > Of-course this also raises the question of 'what happens when the master > > > goes down?'. > > > > I'm following this topic, and I a bit with Qadri. I think it should > > be/stay the responsibility of the user. > > My solution to get up-to-the-minute packages is very simple: > > -put ftp.archlinux.org on top of the mirrorlist > > -do pacman -Sy > > -comment ftp.archlinux.org out of the mirrorlist > > -do pacman -Su > > And then it goes through the list of servers for the latest packages. > > > > Change the way how the mirrors and how updating works is unnecessary IMHO. > > > > Aren't you doing exactly what's being proposed (check the master for the > package list, then download from a faster mirror), just manually? If you > think that it's the best way to do things, why not make it automatic? Low-level tools for more control over what's going on is in this case preferable to a large automated app, in my opinion.
