filters short-circuit in an unexpected fashion

[Commod0re]

Consider the following mirror filters:

1. aptly mirror create -filter='Name (~ python)' ...
2. aptly mirror create -filter='Name (~ python), !Name (= libpython2.7) ...
3. aptly mirror create -filter='!Name (= libpython2.7), Name (~ python) ...

Expected results:

1. contains all packages with python in the name
2. contains all packages with python in the name, except for libpython2.7
3. contains all packages with python in the name, except for libpython2.7

Actual results:

1. contains all packages with python in the name
2. contains all packages with python in the name
3. contains all packages with python in the name, except for libpython2.7

Based on these outcomes, it appears that filtering on packages short-circuits after the first clause that evaluates to true, which is incorrect behavior for a logical AND.

~ % aptly version
aptly version: 0.9.1

[smira]

@Commod0re I'm not able to reproduce that (neither in tests nor reproducing your scenario):

$ aptly mirror create -architectures=amd64 -filter='Name (~ python)' wheezy http://mirror.yandex.ru/debian wheezy
$ aptly mirror update wheezy
...
$ aptly mirror edit -filter='Name (~ python), !Name (= libpython2.7)' wheezy
$ aptly mirror update wheezy
$ aptly mirror show -with-packages wheezy | grep libpython
Filter: Name (~ python), !Name (= libpython2.7)
  libpython2.6_2.6.8-1.1_amd64
  libpython3.2_3.2.3-7_amd64
  libpythonqt2-dev_2.0.1-1.1_amd64
  libpythonqt2.0_2.0.1-1.1_amd64

$ aptly mirror edit -filter='!Name (= libpython2.7), Name (~ python)' wheezy
$ aptly mirror update wheezy
$ aptly mirror show -with-packages wheezy | grep libpython
Filter: !Name (= libpython2.7), Name (~ python)
  libpython2.6_2.6.8-1.1_amd64
  libpython3.2_3.2.3-7_amd64
  libpythonqt2-dev_2.0.1-1.1_amd64
  libpythonqt2.0_2.0.1-1.1_amd64

[Commod0re]

That is interesting. I had no problems reproducing the issue yesterday. Let me see if I can narrow this down a little more.

[Commod0re]

Aha, I figured it out. The problem is not necessarily the filter by itself, but it seems to show up at times when filtering along with dependency resolution.

This example shows a reproduction of unexpected filtering results with aptly snapshot filter:

% aptly -architectures=i386 mirror create -filter='Name (~ python)' test http://archive.ubuntu.com/ubuntu precise
% aptly mirror update test
...
% aptly snapshot create test from mirror test

Snapshot test successfully created.
You can run 'aptly publish snapshot test' to publish snapshot as Debian repository.
% aptly snapshot filter test tf1 -with-deps 'Name (~ python), !Name (= libpython2.7)'  
Loading packages (1995)...
Building indexes...

Snapshot tf1 successfully filtered.
You can run 'aptly publish snapshot tf1' to publish snapshot as Debian repository.
magreene@HAL ~ % aptly snapshot show -with-packages tf1 | grep libpython
Description: Filtered 'test', query was: '-with-deps Name (~ python), !Name (= libpython2.7)'
  libpython3.2_3.2.3-0ubuntu1_i386
  libpythonqt2-dev_2.0.1-1ubuntu1_i386
  libpythonqt2.0_2.0.1-1ubuntu1_i386
% aptly snapshot show -with-packages tf2 | grep libpython
Description: Filtered 'test', query was: '!Name (= libpython2.7), Name (~ python)'
  libpython2.7_2.7.3-0ubuntu3_i386
  libpython3.2_3.2.3-0ubuntu1_i386
  libpythonqt2-dev_2.0.1-1ubuntu1_i386
  libpythonqt2.0_2.0.1-1ubuntu1_i386

It is a little odd to me that doing it this way produces the opposite results of what I was seeing last night, but it does at least show that the behavior can change based on the filter order.

[smira]

That makes sense: first aptly does filtering, then dependency resolution. As dependency resolution algorithm isn't perfect, it may produce different result on slightly different package order.

[avongluck-r1soft]

Is this related to aptly not looking at dependencies of dependencies?

Example: I filter openjdk-7-jre-headless, which depends on libpulse0, which depends on libasyncns0 and others. The dependencies for libpulse0 don't get pulled in with -filter-with-deps