> > Oh, each supplementary file we distribute is a bit of a burden to
> > the maintainer (Auto- tools could help here :-), but more
> > importantly, one more bit of pollution each time the maintainer does
> > `ls' in his/her work files.
Akim Demaille <[EMAIL PROTECTED]> écrit:
> Seriously, there will always be several files, yet because it doesn't
> make sense to have config.guess, config.sub swallowed by `missing' or
> something else. That would be a stupid thing to do IMHO.
I never said nor thought that a `.tar.gz' distribution should unpack in a
single file. :-) However, my opinion is that we should react against the
thread of distributing a flurry of invariant files, where one would do.
> While we're at it, don't you think we should build a single file
> `STUFF' which contains NEWS, COPYING, AUTHORS, THANKS, TODO,
> ABOUT-NLS, ChangeLog, INSTALL, README etc.? Let's face it: there is
> plenty of useless files in there, nobody cares!
Somebody cares! Do not generalise! :-)
NEWS, AUTHORS, THANKS, TODO, ChangeLog and README are variant files, these
are OK to me. (Yet I now think AUTHORS is superfluous: administrative
FSF information should be kept at the FSF, AUTHORS file are doomed to be
either incorrect or dangerous, per our recent discussion :-).
However, COPYING, ABOUT-NLS and INSTALL could be merged into a single
ABOUT-GNU. Moreover, that might also explain many things non-GNU addicts
endlessly need to know: what is GNU, what is the FSF, what is the LPF,
why is the `man' page, how to read or print Texinfo files, bits about long
options, generics about bug reporting, some useful URLs on free software,
and such. ABOUT-NLS and INSTALL do not really need a separate existence
in distributions. (And the translation matrix in ABOUT-NLS would be more
usefully replace by an URL. :-)
OK, if you insist... It could be useful keeping COPYING separate.
> We shouldn't distribute the Makefile.am and configure.in too, there are
> useless for the installer, and waste bandwidth.
Each distribution should give people all what is needed for maintenance,
or at least, good pointers to re-establish a full context of maintenance.
Installers, or even users, should not be considered as lesser people.
> What I'm trying to say is that I don't want to take into account the
> opinion of people who come and say ``there's too many files'', because
> that's not a measure of anything.
As a maintainer, I do not like too many files, or auxiliary directories
where a single file would do. Fewer files is a measure of clarity and
simplicity. regex.[ch], malloc.[ch] or gettext.[ch] may be dozens of file
in their own distribution, but a pair of files is enough for them in mine.
> I too, enjoy to polish my package so that it's cute. But this is a
> minor detail as compared to the runtime existence of the package.
I polish my packages because they are more maintainable this way. Or at
least, because there is more joy for me working in an ordered environment.
There is some anality in my work methods, and we are not all alike :-).
> She cares about the present, not the box.
Such reasonings were behind the poor state `tar' once had. It was a big
horrible mess that nobody, even its few maintainers before me, wanted to
touch, as much as it could be avoided. `tar' just kept there, rotting,
and no one was willing to bear the smell. When I took it, my main goal
was to restore its maintainability, and for the few years I took care of
`tar', I furiously cleaned it. And in some way, I think I succeeded sooner
than expected, as another maintainer became interested in taking it.
> I don't know what you are thinking about `m4', but I see no difference
> between an .m4 file and a .c
C files are variants from package to package. A flurry of invariant `m4'
files distributed in dozens of package is more polluting than useful.
> I expect to receive manageable `.m4' in the packages, not a big
> acincludes.m4 as in the old days.
These `.m4' files should be distributed in a single place, not dozens
of places. I have a special tool geared to compare these little files
to find out the `best' copies out of distributions. This is overhead,
and indicative that things are not being done properly in that respect.
One big `acincludes.m4' for one package is exactly what a package needs.
Currently, the growing trend is using one package to distribute other
packages directly, as such. It just spreads version confusion and complexity
everywhere. Each thing at its proper place, that would be much better.
> PS/ Back to the point: I agree `mkdir -p', `install' belong to
> `missing', but let's make sure we are not building something which
> will become hard to maintain.
Just a comment, here. We used `mkdir -p' all along in this thread, but
I guess it might be better to think `install -d' rather than `mkdir -p'.
--
François Pinard http://www.iro.umontreal.ca/~pinard
