[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#852820: closed by Guillem Jover <guillem@debian.org> (Bug#852820: fixed in dpkg 1.18.21)

Iain Lane writes ("Bug#852820: closed by Guillem Jover <guillem at debian.org> (Bug#852820: fixed in dpkg 1.18.21)"):
> Needless to say, I'm not very happy that the work I spent time on was
> reverted without giving me a chance to rebut. And now this is done, now
> that my work has missed the release (which given the effect of the
> change was somewhat important), you both go silent.

I'm sorry that you're upset.  I'm also sorry that this is causing you
trouble and has meant that something you care about missed the

I'm afraid I remain of the view that your proposed summary of the
autopkgtest metadata is an invitation to misuse.  I don't think the
autopkgtest metadata is amenable to being summarised in a
generally-useful way.  (Even the X-Testsuite flag is a somewhat poor

As a consequence I don't think it is sensible to try to encode enough
data in Sources.gz to solve your problem.

I appreciate that having to dig the metadata out of source packages
can be a performance problem.

> I also don't want to implement a brittle, hard to implement and
> lagging side channel to deliver this information.

Have you considered using a cache ?

> A solution in dpkg-source is superior. It has
> access to all the information we need. Please give me some advice on
> whether there is a way I can satisfy you and implement it in
> dpkg-source.

I think there is nothing that would
  - solve your problem;
  - be brief enough for Sources.gz; and
  - not invite semantically mistaken uses.



Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply to: