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_. 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. 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. But rpmbuild is the wrong tool. * although I'm still interested in the idea of switching over time to Conary! -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
