Bug 440218 – portage should have a ebuild-accessible variable for the USE flags of previously-installed versions

• Product: Portage Development
• Status: RESOLVED WORKSFORME

[Description poletti.marco 2012-10-30 08:04:23 UTC]

In EAPI 4, the REPLACING_VERSIONS was introduced, and this helps make elog messages more relevant (see bug 440214).

To improve the elog messages further, it would be helpful to also expose the information on which USE flags were enabled in each of those versions.

For example, net-misc/dhcpcd-5.6.2 contains the following:

        if use zeroconf; then
                elog "You have installed dhcpcd with zeroconf support."
                elog "This means that it will always obtain an IP address even if no"
                elog "DHCP server can be contacted, which will break any existing"
                elog "failover support you may have configured in your net configuration."
                elog "This behaviour can be controlled with the -L flag."
                elog "See the dhcpcd man page for more details."
        fi

This message is helpful when the user is installing the package from scratch or when the package is being re-emerged adding the zeroconf USE flag, but it's not relevant when the flag was already active.


If it was possible to write something like:

if use zeroconf && !previous_use zeroconf; then
    ...
fi

Then the elog message would only be displayed when it's relevant.


Reproducible: Always

[Comment 1 Zac Medico 2012-10-30 16:22:42 UTC]

(In reply to comment #0)
> If it was possible to write something like:
> 
> if use zeroconf && !previous_use zeroconf; then
>     ...
> fi

You can already do the equivalent since EAPI 2 like this:

  if use zeroconf && ! has_version 'net-misc/dhcpcd[zeroconf]'; then

[Comment 2 poletti.marco 2012-10-30 16:30:36 UTC]

Nice! Thank you.
That function covers all the use-cases that I need, so I think that we can close this bug as INVALID, then.
Or is there some reason to keep it open?

[Comment 3 Ulrich Müller 2020-10-25 17:05:09 UTC]

(In reply to poletti.marco from comment #2)
> That function covers all the use-cases that I need, so I think that we can
> close this bug as INVALID, then.

Closing.