Re: Use of the m4 macros and standard package

[Patrice Dumas]

> 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