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. On the other hand we do need to get people to be proactive here. Being reactive is just not good enough. By that I mean you can't just break something and expect other people to clean it all up for you when you do, as a good community member it's up to you to inform people about the impending breakage and how you plan to fix dependent packages, ideally so they all rebuild the same day and cause no breakage to the repo/composes/users. In addtion to the updates policy Adam quoted downthread there is also: https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages It's just good community to communicate changes like these and try and minimize their impact. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
