On Wed, Feb 28, 2018 at 09:51:49AM -0800, Kevin Fenzi wrote: > On 02/27/2018 06:06 PM, Adam Williamson wrote: > > On Tue, 2018-02-27 at 19:41 -0600, Richard Shaw wrote: > >> On Tue, Feb 27, 2018 at 6:47 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> > >> wrote: > >> > >>> Richard Shaw wrote: > >>>> Is it time to update the packaging guidelines to enforce setting a > >>>> "%global sover <X>" and using it in %files? > >>>> > >>>> If nothing else it should at least be documented as a best practice. > >>> > >>> Not yet another bureaucratic guideline making it harder to maintain > >>> packages! > >>> > >>> Hardcoded soversions in specfiles are a pain! > >> > >> > >> Unannounced soname bumps are a pain :) > > > > Right. It's not "bureaucratic" if it's a specific response to a real > > problem that keeps happening. That's more or less the *opposite* of > > bureaucratic. > > I don't think we need to "force" (how do we do that?) not using globs in > file lists on libraries. If you maintain some package and have other > ways of noticing the soname change, great. (inspection, local testing, > abicheck runs, etc). Personally, I think it's a good idea and best > practice to not use globs there so you can't help but notice, but that > seems to me a workflow detail. I've seen plenty of cases in the past where RPMs have silently had a build 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. 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 :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
