On 4/1/20 4:24 PM, Stephen Gallagher wrote:
On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> On 3/31/20 3:34 PM, Stephen Gallagher wrote:
>> On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen <pmatilai(a)redhat.com>
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?
This latter case is what I meant by the above, apparently not very
clearly :)
Care needs to be taken though when adding "meta" to things like this as
in many cases the order *does* matter.
- Panu -