Hi, folks. Looks like there was an unannounced soname bump in Rawhide today: libpsl.so.0 -> libpsl.so.5, in package libpsl. Looks like the only other package using that lib is wget, so that needs rebuilding. I'll try a straight rebuild, if that doesn't work I'll contact the maintainer.

On Mon, Feb 1, 2016 at 2:58 PM, Yaakov Selkowitz <yselkowi(a)redhat.com > wrote: > On 2016-02-01 07:45, Adam Williamson wrote: > >  Hi, folks. Looks like there was an unannounced soname bump in > > Rawhide > > today: libpsl.so.0 -> libpsl.so.5, in package libpsl. Looks like > > the > > only other package using that lib is wget, so that needs > > rebuilding. > > I'll try a straight rebuild, if that doesn't work I'll contact > > the > > maintainer. > > > This is the hazard of using %{_libdir}/*.so.* in %files.  Is there > any reason why such a syntax should NOT be formally discouraged in > the packaging guidelines? That would only fix problem where upstream is well disciplined and properly manages soversions. If I have any doubt I always build test packages and do a comparison with abi-compliance-checker. 

On Tue, Feb 2, 2016 at 2:19 AM, Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: > On Mon, 2016-02-01 at 15:02 -0600, Richard Shaw wrote: > > On Mon, Feb 1, 2016 at 2:58 PM, Yaakov Selkowitz <yselkowi@redhat > > .com > > > wrote: > > > On 2016-02-01 07:45, Adam Williamson wrote: > > > >  Hi, folks. Looks like there was an unannounced soname bump > > > > in > > > > Rawhide > > > > today: libpsl.so.0 -> libpsl.so.5, in package libpsl. Looks > > > > like > > > > the > > > > only other package using that lib is wget, so that needs > > > > rebuilding. > > > > I'll try a straight rebuild, if that doesn't work I'll > > > > contact > > > > the > > > > maintainer. > > > > > > > This is the hazard of using %{_libdir}/*.so.* in %files.  Is > > > there > > > any reason why such a syntax should NOT be formally discouraged > > > in > > > the packaging guidelines? > > That would only fix problem where upstream is well disciplined > > and > > properly manages soversions. > > > > If I have any doubt I always build test packages and do a > > comparison > > with abi-compliance-checker. > > Sure, but handling it most of the time is better than handling it > none > of the time. I agree with Yaakov that the guidelines should > discourage > spec files using globs for soversions. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > I'll admit that I'm guilty of this when I craft packages targeting Fedora. For the most part, it's because I don't have a good reason to care about the soversion (aside from making sure it exists). When I'm making packages targeting Mageia or openSUSE, I do actually care about it, because the library package is supposed to include the soversion in the name. Fedora's guidelines don't require the soversion to be part of the package name (which I like), but at the same time, it's a bit disconcerting that our repository policies and the way Yum/DNF work do not allow us to take advantage of RPM's capability to parallel install multiple versions of a package with the same name. Provided that they don't have file conflicts, I don't see why this isn't supported in Yum/DNF. I do understand it adds a bit of burden onto Fedora to maintain a multitude of library package versions, but it's rather bizarre that Fedora is the only major distribution I know of that doesn't have a consistent policy on dealing with cases where multiple versions of the same library package must exist (either temporarily or permanently). I've seen different conventions used across the board, which makes things very confusing...

On Tue, Feb 02, 2016 at 10:20:32AM +0100, Adam Williamson wrote: > The reason to not use globs anyway, though, is simple and exactly the > one in this thread: when the soname changes, all the package's > dependencies need rebuilding. Thus, as the packager, you need to know > when the soname changes. If you use a glob for the filename, you don't > automatically know when the soname changes. If you don't use a glob, > you do automatically know when the soname changes. Thus it's better. On the one hand, okay, yes. But on the other -- ow. This is poking ourselves in the eyes with manually-controlled sharp objects when we should be doing it automatically. (Uh, wait. You know what I mean.)

This approach really scales badly and creates busywork.

Ideally, every line in a package definition (specfile or what have you) is only there because of some exception from the typical case. For well-behaved upstreams, the perfect packaging description would be _empty_.

I agree that it's useful for a tool to tell you when there's a soname change -- or anything _else_ that might affect other packages.

On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote: > >This approach really scales badly and creates busywork. > And breaking rawhide however often due to unnoticed soname bumps > does scale well and does not cause busywork? Right. Tooling should stop that too. And I'm not just talking _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where any package build which breaks other packages (or possibly other integration testing) gets automatically shuttled to a temporary side repo.

>>Right. Tooling should stop that too. And I'm not just talking >>_completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where >>any package build which breaks other packages (or possibly other >>integration testing) gets automatically shuttled to a temporary side >>repo. >That's a good idea. This is good idea for releases, but would be utterly counter productive to rawhide. You'd end up with not being able or drowning in bureaucracy e.g. to add SONAME breaking changes.

>Why bureaucracy? Because this cannot work without coordination in a multi-admin world => Fedora is not a Cathedral, so bureaucracy is inevitably required.

It's what buildoverides in releases are aiming, and ... they are a pain to use and are far from working perfect.

>That said, the current idea is to leave Rawhide as is, and add a >separate "gated" layer. That gated layer already exists. It is called "releases".

> Rawhide is broken too often too easily, leading to too few > contributors/developers running it, leading to more problems. Is the Fedora Project still not doing anything to change that?

As long as some developers continue using Rawhide as a dumping ground for stuff they don't even use themselves, its quality won't increase. You can aim at blocking packages with dependencies that don't resolve, but that won't be enough, since it won't avoid all runtime issues.

No, but it would be a good start. Maybe koji can automatically open a ticket on bugzilla for all packages that require a rebuild due to an soname bump (if the package Requires either the package or has a query-able reference to that library). Automatically attempting a scratch rebuild of the dependent packages to see if there are any breaking changes would be nice too.

> Right. Tooling should stop that too. And I'm not just talking > _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where > any package build which breaks other packages (or possibly other > integration testing) gets automatically shuttled to a temporary side > repo. I think I asked this question before, but I don't remember the answer. Will Dennis's work include some way of letting high priority packages break low priority packages? As an example, I maintain the polymake

Either way, we should let polymake break and let me fix it as soon as I can. Perl updates should not be delayed. Will that be possible?

Ideally, every line in a package definition (specfile or what have you) is only there because of some exception from the typical case. For well-behaved upstreams, the perfect packaging description would be _empty_. With all of our legacy, we can't really do that*, but I think it's better if we move _towards_ it rather than away. It makes package creation easier (and easier to automate), and it makes _review_ much _much_ easier, simply because there's less to look at and everything you do look at should be significant rather than boilerplate.

  Even if the spec file uses wildcards to include any shared library version, the automatic dependency checks for Rawhide will notice the SONAME change and inform the packager about it. => The packager will need to take proper action and not dump incompatible packages into the updates repo for stable dist releases. Unfortunately, some packagers seems to miss the broken deps reports or ignore them and perhaps are not aware of the consequences either. Oh, and I think we've also had some packagers not using wildcards and still rushing out with incompatible library updates simply because they underestimated the breakage.

This is the hazard of using %{_libdir}/*.so.* in %files. Is there any reason why such a syntax should NOT be formally discouraged in the packaging guidelines?

Why would it be a pointless edit? Surely you are editing it to update to the new version, why wouldn't you also just edit it to adjust the so files? or do you not test your version upgrade specs before firing off official builds?

There's a difference IMHO between a known bug (which is actively being worked by upstream) that prevents you from compiling and a known bug that prevents already existing things from working.

On Wed, Feb 03, 2016 at 11:27:30PM +0100, Kevin Kofler wrote: > Yaakov Selkowitz wrote: > > This is the hazard of using %{_libdir}/*.so.* in %files. Is there any > > reason why such a syntax should NOT be formally discouraged in the > > packaging guidelines? > > There is: I do not want to have to pointlessly edit my specfile each time > some soname changes, and waste a failed build (i.e., ultimately MY time). In other words, you are saving YOUR time at the cost of OTHER PEOPLE's time. Because, until all the necessary rebuilds are done, EVERYONE building a package that transitively depends on your package will get a failed build. With the added "bonus" that noone of the affected people does know if the soname bump is deliberate or if it was pushed and built unintentionally.