On 2016-02-02 04:10, Matthew Miller wrote:
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.)
An soname change is something the maintainer should be consciously aware
of *before* it is shipped, so that the ramifications thereof can be
dealt with *in advance*. (Or, as has happens occasionally, the change
is actually a mistake, which has its own set of possible ramifications.)
By the time a build hits rawhide, it is too late for due diligence.
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?
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 don't see how %files could ever be implicit.
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.
This is something that should be caught by the-new-hotness scratch build.
--
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
