using apt-cache in autopkgtest and test cases
Hi,
On 30-12-16 15:24, Martin Pitt wrote:
>> During this work I found out that the preferences file (the apt pin
>> file) is blindly assigning the release as found in /etc/apt/sources.list
>> to the suite (a= field), while it could contain the codename (n= field).
>
> I'm not very familiar with the difference, but I believe the difference is
> exactly in what Launchpad calls "pockets" (I'm not aware of a corresponding
> name in dak): I. e. a package from "stretch-updates" would have
> a=stretch-updates, but still n=stretch, so that it seems to me that n= is not
> sufficient for --apt-pocket.
No, the difference is sid vs unstable, jessie vs stable, stretch vs testing.
>> In my current implementation I parse the output of apt-cache to
>> determine the the value for the a= field, but I learned that testing
>> with apt-cache isn't trivial as it requires all kind of files with
>> reasonable content in /var/lib/apt/lists/.
>
> I'm not sure what you are trying to do, but ISTM that --apt-release might
> actually use n= while --apt-pocket keeps using a=?
I don't think so. See below.
> Also, if this is only for tests: I don't think it's a good idea to try and fake
> the output of apt-cache -- for the SchrootRunner tests I'd actually use some
> existing Debian releases/pockets such as stable vs. stable-updates.
Well, the code so far works (as far as I tested), but it fails in the
regression test because there is no data in /var/lib/apt/lists in the
small test chroot.
>> What do you think, should I just assume the same as the current
>> implementation, i.e. a value that is valid for the a= field, or should I seek
>> harder for an other way of checking
>
> Can you please explain the actual problem? I don't think autopkgtest should try
> and do any interpretation/dissection of the release -- it should pin the
> archive name exactly to what you specify. Why doesn't this work?
The actual problem is that in /etc/apt/sources.list one can use both
jessie or stable (the codename or the suite) to tell apt which release
to follow (obviously, one of these will move to use old-stable soon,
while the other will follow stretch soon), while only stable is valid in
the current a= field in the preferences file. So writing out the
preferences file in autopkgtest should either change the field n=/a= or
convert a codename to the suite name. In my current implementation, I do
the latter.
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161230/aae56f27/attachment.sig>
Reply to: