[muon] libmuon/backends/ApplicationBackend/tests: Introduce a new test within the SourcesTest for APT

[Aleix Pol]

On Wed, Jan 14, 2015 at 10:03 AM, Harald Sitter <sitter at kde.org> wrote:
> On Wed, Jan 14, 2015 at 5:05 AM, Aleix Pol <aleixpol at kde.org> wrote:
>> Git commit 88433b3fd9ad816f1ac05d6f5205cc03165eac84 by Aleix Pol.
>> Committed on 14/01/2015 at 04:04.
>> Pushed by apol into branch 'master'.
>>
>> Introduce a new test within the SourcesTest for APT
>>
>> Tries to ensure that the origins of the packages maps to one of the offered
>> sources.
>> Problem is, it doesn't work well, many packages provide an empty origin "".
>> CC'ing kubuntu-devel, hoping they will know how to fix this.
>
> Doesn't fail for me :S
> Could you give us a list of packages that are listed with no origin
> and perhaps check where they are coming from (apt-cache policy $name)
>
> Generally speaking though there doesn't need to be an origin attribute
> as this is purely optional and defined in the repository metadata [1].
> In fact repository metadata can be missing entirely if a package is
> installed but has no actual apt repository associated with it.
>
> As a very simple example when one would not have an Origin because
> there is no repository: If a user installs Skype manually through a
> deb it will show up in the package cache, what with being installed
> and all. It will however not have an Origin or Site or similar
> attributes that would be coming from a repository as it has no
> repository associated with it, it was but a lonesome deb.
>
> [1] https://wiki.debian.org/RepositoryFormat#Origin
>      "Optional field indicating the origin of the repository, a single
> line of free form text."
>
> HS

It doesn't fail because of the QEXPECT_FAIL.

Ok then, I'll try to treat the empty origin as an unknown one,
although TBH I really had far too many empty ones. I'll send you a
list of my output tonight.

Aleix