On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > > On 3/31/20 3:34 PM, Stephen Gallagher wrote: > > On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > >> > >> It's that time of year again... as our RPM change proposals passed with > >> flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in > >> rawhide later today or tomorrow by latest. > >> > > > > Since Panu left it out of his announcement, I'd also like to mention > > that RPM 4.16 adds the following new feature: > > > > "Add support for meta dependencies (eg Requires(meta): somepkg) that > > do not affect install/erase ordering (RhBug:1648721)" > > > > These dependencies are intended for use with metapackages and help > > with avoiding dependency loops. Essentially, a `Requires(meta):` > > dependency is telling RPM: at the end of any transaction where this > > package is installed, this dependency must also be installed, but I > > don't need the dependency ordered earlier. > > > > This is going to come in handy for the Fedora Release packages (like > > fedora-release-server) which will be able to define a minimal "API" to > > be recognized as that Edition (or Spin). This didn't work before this > > feature was added, because fedora-release must be ordered early in the > > transaction to set up things like /etc/os-release, so we couldn't set > > dependencies. > > Oh, thanks for the reminder about this Stephen. > > Besides meta-packages, another potential use-case for meta (whether > Requires or weak dependencies) is those just-in-case dependencies across > sub-packages to ensure nobody runs weird combinations even though > sonames might permit it. Often they are in the same direction as the > soname dependency so it doesn't create any additional ordering issues > but sometimes they're in the opposite direction, creating a wholly > unnecessary dependency loop. Rpm itself is an example of this (but we > can't really use "meta" anytime soon as rpm needs to be bootstrappable > from older versions) Do you mean things like: Requires: libfoo >= 3.4.2-3 could become Requires(meta): libfoo >= 3.4.2-3 What about things like ensuring that subpackages are running the same version as the main package so they get updated together? _______________________________________________ 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
