> Sure, it is not standard, but that's not just capriciousness or > laziness: the whole idea of gnulib is to share files *at the source > level*. If people are not comfortable with cvs checkouts (and autoconf > and ...), they shouldn't be using it.
Indeed, but having gnulib only in the cvs form has some drawbacks, like being hard to package and deploy easily on many hosts dispersed accross different networks. Imagine someone doing coding at 6 places (5 labs and a home), having set up a yum repository at one location. It is much easier to rebuild the gnulib at that location and have it automatically updated on all the networks. It is even more interesting in case there are co-workers at those places. Indeed it is possible to use scripts to do the cvs update and distribute the gnulib at each site with a distributed filesystem. But why use other systems when established tools exists that are more suitable? One could even imagine that for an entire distribution somebody updates a package often, say one time a week or a month from cvs and rebuilds the package. I think this could be done for example in the fedora extras, I don't know about other projects but there is no reason it couldn't. It could also help for computers without direct net access. > The problem with using it from an installed location is that then a > release has to be downloaded and installed. That is two extra steps > (which many people would not bother to do, so out-of-date files would > proliferate) that are a burden with no upside, as far as I can see. No packaging is a real downside. > At one point Debian was making a package out of it, although I tried to > discourage this. Any kind of release or package will inevitably be out > of date the day it is released, and it's not practical to make a new > release every time a file changes. Gnulib is a collection of disparate > functionality updated piecemeal nearly every day. Isn't that the case of many open source projects? With your reasoning all the big opensource projects shouldn't do any release and be only accessed with version management systems. I can't see the issue with having out of date releases. If a developper wants to have the bleeding edge then he uses cvs. Still there are packaged releases for the others. That's not different from other packages. If you don't want to make releases, at least if there is an infrastructure then the packagers would be able to do make distcheck and package it. Having few releases should be enough in my opinion. The gnulib has allready so much features that the pace of the releases is not an issue. Of course there should also be releases when a security issue has been detected or big bugs are solved. Regarding security issues and other bugs as well, having releases also helps advertising the issue and simply points to fixes. Especially since projects use a snapshot of the gnulib being able to identify which snapshot it is to know whether it is needed to rerelease a project with newer gnulib or not bother about it. -- Pat _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib