[pacman-dev] Version bounds for IgnorePkg
Daniel Schoepe
daniel at schoepe.org
Sun Jul 5 12:44:26 UTC 2015
On Sun, 05 Jul 2015 14:01 +0200, Allan McRae wrote:
>> - As discussed when I brought this up a while back, only equality constraints
>> are supported, since the other types of bounds would have unclear semantics.
>
> Can you clarify what is unclear there? At first glance I would think
> that "IgnorePkg foo < 5.0" would be useful.
You're right, this sounds like a useful constraint as well. Not sure if
something like "foo > 5.0" would also have some use cases, but allowing
it won't hurt, I suppose.
On the implementation side, this makes things a bit more tricky, since
the code in sync.c also checks if the locally installed version is
matched by IgnorePkg / IgnoreGroup. For example, when having foo-1.0
installed and setting IgnorePkg foo<1.1, an update to foo-1.2 will be
ignored, since the locally installed version matches foo<1.1.
I'm not sure what the motivation is for taking the locally installed
version into account. It might be sufficient to only check the package
that's about to be installed.
>> - This is checked for by pacman and libalpm assumes that only such IgnorePkg
>> entries are added. I'm not sure if this check should rather be handled by
>> libalpm instead.
>
> I think this needs to be in the backend. The all frontends benefit.
>
>> - alpm_handle_t.ignorepkg is now a list of alpm_depend_t structures, not
>> strings. This required some more widespread changes to avoid duplicating the
>> code that handles assumeinstalled entries.
>
> I'd see a string being passed to the backend which converts it to
> alpm_depend_t. And having it is that type will need a comment in the
> handle field that we are reusing that struct to have versioning on ignoring.
At the moment, alpm_depend_t is also used for assumeinstalled, with the
conversion being done by pacman. For example,
alpm_option_add_assumeinstalled takes a depend_t structure as an
argument and assumes that the conversion is done before interacting with
alpm. I guess we should be consistent and either handle both in alpm or
both in pacman (or other frontends).
Best regards,
Daniel
More information about the pacman-dev
mailing list