On Thu, Mar 18, 2010 at 09:45:14PM +0100, Ralf Treinen wrote:
> That's of course a possibility. Though the cases that I have been told
> about always had a different explanation, if memory serves me right.
ACK, can you please apply the patch I've posted? That's a needed bug fix
anyhow.
> I am really disappointed that I can no longer blame python for this bug
> (but don't worry, I'll find something else to blame python for :-)
Eh :-)
> Dropping a build-dependency on a build-essential package is of course
> only correct when
> - and if it occurs as element of a conjunction, not as element of a
> disjunction: true and x is equivalent to x, but true or x is not
> equivalent to x.
This point if of course correct, I'll fix add-sources.py to properly
cover that (in a few days though, I'll be traveling between today and
tomorrow).
> - it is an unversionend build-dependency
> A correct simlification would be to simplify (..|x|..) to True, that
> is remove it simply from the conjunct, in case x is build-essential
> and has no version constraint.
This is a bit less clear. In principle it is of course correct too, but
we will end up again with the fact that not necessarily essential
build-deps are installable according to only the Packages file (as
Julien promptly detailed saving my memory from the blame!). So,
_keeping_ an essential build-dep just because it is versioned can make
edos-debcheck fail later on even if the build-dep is properly installed.
So, to wrap up, we have various possibilities to fix this. The first one
is the one you suggested here:
> we put this stuff in the first place. I guess it was due to some
> mis-guided ideas about optimization. I suggest we just scrap it.
According to the bug log given by Kurt below, this does not look correct
though (so no, it does not look it was an optimization).
On Thu, Mar 18, 2010 at 11:15:24PM +0100, Kurt Roeckx wrote:
> > This, in turn, is by design :-) I don't remember if I or someone else
> > added the support for it, but we currently have a list of
> > build-essential packages, which currently reads as follow:
> >
> > buildessentials = ['apt', 'binutils', 'cpio', 'cpp', 'dpkg-dev',
> > 'g++', 'gcc', 'libc6-dev', 'make', 'patch',
> > 'perl', 'perl-modules']
>
> See #545381
> The problem is that it's not libc6-dev on all arches.
The second one is fixing this once and for all: i.e. having
builddebcheck read from the outside the list of package it must assume
to be installed. According from the bug log however, there didn't seem
to be a sane way to feed builddebcheck with that info ....
The third possibility is for now to just fix properly the "OR
optimization" as I said above. It looks like it will fix _this_ specific
case, but can of course fail in other/weirded cases.
Thoughts?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature