[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