On Thu, 2018-03-01 at 06:21 -0500, Matthew Miller wrote: > On Wed, Feb 28, 2018 at 01:29:38PM -0500, Simo Sorce wrote: > > > 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. > > > > If you still have to keep a list, why is it better to keep it in tests > > Separation of concerns. But also, you shouldn't have to keep a list per > se, just annotations of when it's okay that the list has changed. On way would be to eliminate lists completely except for special cases, like removal of things we do not want to distribute. It could be accomplished by changing our tooling[*] to use overlay filesystems to figure out exactly what a make install did and pick only those files. But unless we have that kind of automation we will always have to maintain a list and I'd rather have it all in one single place (the spec file) rather than multiple places that you then have to reconcile. Simo. [*] I know this is easier said than done, and comes with it's bag of issues. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx