couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Getting rid of file lists in documentation Makefiles
Date Mon, 20 May 2013 21:29:20 GMT
My concern is that when you use wildcards, a malicious (or broken) program
could add files to the output that are then bundled up, and we end up
shipping them in a release. At the moment, every file that we ship has been
explcitly included. Having said that, my release procedure is now
sufficiently advanced that I can detect missing/extra files, as well as
"surprising" content. So I am not sure I need to be as vigilant about this
as I used to be...

With that in mind, I'd say:  do whatever you think is best.

On 20 May 2013 21:55, Dirkjan Ochtman <> wrote:

> On Mon, May 20, 2013 at 5:39 PM, Noah Slater <> wrote:
> > I'm torn on this issue.
> >
> > See:
> >
> >
> >
> > (Please read that whole section.)
> >
> > Summary is:
> >
> >  * Wildcards make it easy to distribute the wrong files (either too
> many, or
> > too few)
> >
> >  * Wildcards are not portable
> Yes, I understand the concerns. On the other hand, I don't think most
> of those concerns apply cleanly to for example a Sphinx project. In
> particular, Sphinx already complains if src files are either missing
> or unused, so you'll get warnings about that. And Sphinx populates the
> build directory from scratch every time, so problems with the HTML
> output also seem fairly unlikely. On the other hand, forgetting to
> update the file lists in the will have no effect on
> building the docs, but will fail make distcheck. To me, at least, in
> this context, DRY a bigger concern to me.
> To be fair, portability is a concern. Dave, does the typical Windows
> build environment already have a find tool available to it? (Either
> just some compiled GNU tools or a full Cygwin environment?)
> > Please also consider that with Benoit's rcouch merge, we're moving away
> from
> > Autotools entirely (I believe), so we will have the chance to throw off /
> > simplify a lot of this stuff.
> Ah, yes. Do we have a time frame for that?
> > What are your thoughts having read that section?
> Still the same, in this particular context, for the reasons explained
> above.
> Cheers,
> Dirkjan


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message