Re: HEADS UP: RPM 4.19 soname bump in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri May 19, 2023 at 22:59 +0200, Michal Domonkos wrote:
> On Fri, May 19, 2023 at 05:37:06PM +0100, Richard W.M. Jones wrote:
> > Nevertheless I do believe if the librpm changed its API then every
> > package which _BuildRequires_ rpm-devel should be rebuilt, just to
> > check the change doesn't affect them.
>
> Yes, we were primarily focusing on runtime dependencies now so that Rawhide
> isn't broken when the side-tag is pushed, however any API incompatibility in
> the packages that BuildRequire rpm-devel would just be pushed back to the
> earliest moment they're rebuilt in Rawhide by their maintainers.
>
> So I also think that ideally we should try rebuilding those ourselves to
> identify potential issues while 4.19 is not yet in Rawhide.
>
> I'll talk to my team on Monday, we'll perhaps do just that.  A quick check with
>
>     dnf repoquery --release=rawhide --disablerepo="*" --enablerepo="*-source" \
>                   --arch=src --whatrequires rpm-devel
>
> shows a couple of additional packages that weren't covered in this thread so
> far

I guess I'll plug fedrq [1] here, as this type of situation (a long
thread about how to properly use dnf repoquery to find reverse
dependencies) is one of my motivations for writing that tool :).

If you're looking for any package that requires (any virtual provide) of
rpm-libs or rpm-devel at buildtime or runtime, this query will get you
there:

    $ fedrq wr -X -F source rpm-devel rpm-libs

...


The `-F source` option prints out a single deduplicated list of source
package name. If a package in the final query is a source package, the
`source` formatter spits out the package {NAME} and if the package is a
binary RPM, it spits out the package's {SOURCE_NAME}.

`-X` is short for `--exclude-subpackages` and will make sure rpm itself
doesn't show up in the output ;).

You can pass `-b rawhide` to explicitly query the rawhide repositories,
but that's already the default (unless you change it in the config file).

fedrq of course supports the .so name based queries, but I think it's
much better to unintentionally rebuild a couple packages that don't
*need* to be rebuilt and potentially find an FTBFS in advanced than to
unintentionally miss something.

[1] https://fedrq.gtmx.me/

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/They
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux