Re: Default to fetching from CDN first?

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Sep 13, 11:20pm, Roland Illig wrote:
} Am 13.09.2019 um 20:33 schrieb Greg Troxel:
} > <rillig-baiting>Now, if pkglint could optionally warn when the upstream
} > distfile is no longer fetchable, and cache this so it never checks more
} > than once every 30-90 days, that would be cool.   Of course, this is
} > disconnected from the choice of where to fetch first.</>
} 
} I intentionally wrote pkglint to operate in offline mode only.
} 
} [snip]
} 
} Pkglint also doesn't extract the distfiles. I thought about this, for
} checking whether the GNU configure scripts run "test $var == yes", which

     This is automatically done when you build with PKG_DEVELOPER=yes.
Having pkglint do it would be redundant.

} is not portable; this would make the actual builds a bit faster. Since
} extracting the distfiles is expensive, this would need to be hidden
} behind a new command line option, such as --expensive or -Wexpensive.
} Another possibility would be to check the files in WRKDIR _iff_ they are
} already extracted. But that's a whole new topic, and pkglint would grow
} much larger than it already is. Another possible pkglint check would be
} to cross-check the license declaration in the distfile, which is
} currently done by wip/ninka.

     Since pkglint already checks for a LICENSE= in the Makefile,
it probably wouldn't be a stretch for pkglint to look in
/usr/pkgsrc/licenses for the file.  Looking in the package to try
to determine what licenses it uses is not likely to be a reasonable
thing to do.

} Pkglint also doesn't run bmake in any way. Running "bmake clean" would
} interfere with the package developer, who may have some unsaved patches
} lying around.

    Yes, an unexpected "bmake clean" would be a very bad idea.

} Because of the above reasons, I would rather delegate this task to a
} completely separate tool. It could be based on the pkglint code, sure,
} but I'd rather call it distlint.

     We already have lintpkgsrc would could possibly used for this.

}-- End of excerpt from Roland Illig