On Thu, Nov 03, 2022 at 04:01:58PM +0000, Gary Buhrmaster wrote:
On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen
<ssmoogen(a)redhat.com> wrote:
> Or they will just do what I used to do long ago and just do a temp spec file with
some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` and replace the data in
the pushed spec with the list. Nothing is caught because few people have time for the
several hundred packages they are maintaining.
As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section. Which, technically,
meets the requirements, while not dealing
with the intent at all. I think this is really
a question of scale. For smaller packages
with a small number of expected files,
listing them explicitly is going to be a
smaller burden to add or maintain, but for
larger packages (arguably exactly the
ones that are more likely to "stomp" on
other files and you want to catch changes
for), the work is likely much higher (to the
point that one adds in automation to hide
the work).
I don't think that the scale question is a big factor here
because this is a one-time hit when creating the spec. If a
package install 1000 files into %{_bindir} or %{_includedir}
by all means use a script to automate the filling of %files
without wildcards, when first authoring the spec file.
On subsequent updates to new releases, the projects are not going
to be adding/removing huge numbers of files in these directories.
You'll be looking out for a small number of changes, just like any
other package regardless of scale.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|