Alexandre Oliva <lxol...@fsfla.org> skribis: > On Jul 12, 2013, l...@gnu.org (Ludovic Courtès) wrote: > >> Since we’re about to release a new version of Guix, I’d rather keep >> using 3.3.8. > >> Alexandre: could you reinstate the original >> http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu/linux-libre-3.3.8-gnu.tar.xz? > > I suppose you don't want to prevent users of guix from using ath9k wifi > cards, so I strongly suggest switching to 3.3.8-gnu1.
Of course not, but again, this one is used to get headers against which to build glibc, so that’s not a problem. > Indeed, I think you'd be better off with some LTS version of GNU > Linux-libre, rather than the dead 3.3 branch. But that's your call. When we have a stand-alone, bootable distro, we’ll certainly want to synchronize with you for the choice of the default kernel version. >> It would be ideal if the tarballs were on ftp.gnu.org. I could do it if >> you don’t want to bother, provided the FTP admins allow it. WDYT? > > I'd be glad with such an arrangement. Great. > Now, another possibility that I think would make more sense for guix is > to have its sources consolidated in a single place, rather than > scattered all over and at risk of having them pulled from under you. Actually, our continuous integration server at http://hydra.gnu.org does that transparently: it caches all the source tarballs, along with build byproducts. So when a tarball vanishes from its upstream site, it’s usually not a blocking problem. Yet, it’s preferable to have them elsewhere, because they will eventually be garbage-collected from hydra.gnu.org. [...] > When we get GNU Linux-libre at ftp.gnu.org, it could then be hard links, > so that if we remove some tarball it won't go away from your “copy”, but > until then, you might be better off holding your own copy rather than > assuming our primary repository has infinite space. Unfortunately it > doesn't, and I have to clean things up quite often. For sources, I at > least keep enough bits around that the tarballs can be reconstructed in > a bit-exact fashion, but for binaries, when they're gone, they're gone > forever. However, considering we put out multiple GBs of builds per > week, I don't think it's realistic to keep them all forever. Not in our > own server, not at ftp.gnu.org. What do you mean by “multiple GBs of builds per week”? Linux{,-Libre} releases are not that frequent, are they? The policy at ftp.gnu.org has always been to keep everything forever, AFAIK. If size turns out to be a problem, we could choose to keep only LTS releases on ftp.gnu.org, for instance. That’s something to discuss with the GNU sysadmins. Thanks for your feedback! Ludo’.
