On Wed, Feb 28, 2018 at 12:38 PM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
On Wed, Feb 28, 2018 at 01:12:03PM -0500, Matthew Miller wrote:
> On Wed, Feb 28, 2018 at 05:57:53PM +0000, Daniel P. Berrangé wrote:
> > mistake that caused files to go missing, and was never detected by the person
> > making the change, because of the use of globs. So I agree it is good practice
> > to explicitly list files without globs whereever it is practical todo so. I'd
> > make an exception for files which don't have functional impact eg don't list
> > 1000 HTML files individually, but it is always worth listing everything in
> > /usr/bin, and /usr/lib(64) explicitly without globs.
>
> I used to agree with this, but I've come around to thinking that spec
> files should be smaller, less complicated, and more automatable. I
> think we'd be better having a post-build test warning that this package
> has files missing from the previous build. That could be advisory, or
> it could even gate, with the packager clearing the gate by updating the
> file list in the test, rather than in the spec file.
The further down the workflow a problem is detected the more time expensive
/ disruptive it is to fix it. So while having post-build tests to validate
lots of things is great (and I wish we had more of it in Fedora), I see it
as complementary to anything that we can do to detect problems earlier. I
rather see failures right away when I test the new RPM build locally, than
waiting to push it through koji and wait again for post-build tests to find
the problem, as by that time I've context switched my mind away to a
different bit of work.
I don't have the infra experience to implement, but what about adding adding a pkgdiff option to fedpkg where it would complete a scratch build (--srpm if necessary) and then run pkgdiff against it and the current packages in the repository and putting the report somewhere accessible?
Another idea might be to have a way through the copr-cli to create a private copr project on the fly, build the new package and then attempt to rebuild all dependencies with it. That way it can be done completely "offline" and you'll know if you're likely to break anything before doing official builds.
Thanks,
Richard
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
