Re: make mdi and fetch/checksum

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Fri, Jul 11, 2008 at 03:56:56PM +0200, Dieter Baron wrote:
> In article <20080711131157.GA570%britannica.bec.de@localhost> Joerg wrote:
> : On Fri, Jul 11, 2008 at 02:50:05PM +0200, Dieter Baron wrote:
> : > In article <20080711114512.GE648%britannica.bec.de@localhost> Joerg wrote:
> : > : On Fri, Jul 11, 2008 at 01:34:15PM +0200, Dieter Baron wrote:
> : > : > 3. or should we add a special flag to fetch/fetch to not consider it
> : > : >    an error and have make mdi set it?
> : > 
> : > : I prefer (3)
> : > 
> : >   So that flag will be set when NO_CHECKSUM is set, and mdi will set
> : > that flag or NO_CHECKSUM?  Would you be willing to implement that?
> 
> : The flag will be set if mdi is called. FAILOVER_FETCH shouldn't run for
> : unversioned files anyway, but I never tried that.
> 
>   What are unversioned files, and how do they relate to checksums?

Essentially files that we want to mirror to get a consistent answer.
At least one of the theme packages falls into this category.

> : > : and I would prefer if NO_CHECKSUM is obsoleted and all
> : > : cases where it is being used are fixed to include proper checksums.
> : > 
> : >   That won't work for packages tracking daily snapshots.  I know you
> : > dislike these packages, but they are useful and we will continue to
> : > support them.
> 
> : Most cases of NO_CHECKSUM are now redundant. The remaining cases fall
> : into daily snapshots (yes, I strongly dislike them and would prefer to
> : see them in wip only)
> 
>   What would that change (in the current context)?  Our infrastructure
> must also support wip.

First of all, we should have clean rules when and when not NO_CHECKSUM
should be set. It is and was used far too often. The redundant parts are
packages with DISTFILES= #empty as the dependencies are now conditional.
So what remains are files that just change from time to time without
changing the name (above unversioned files) and files that regulary
change names. I'd prefer to not have any of the latter in pkgsrc, it
kind of violates the idea of the branches for example. I am strongly
against the former.

Joerg